Specify limits for output visualizers and some recommendations #537
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #530 and #531.
The part about portability is of course highly subjective, but I think we can all agree that we should try to strive to make problem packages portable for the foreseeable future?
We should probably create a concrete example in
examples. I tried using std_image_write.h, and it seems to work well.I used it as a basis for timing: 5 seconds seems to be plenty of time.
Here's the output of timing, running single-threaded on 3.6GHz processor (Intel i5-8600K), running on WSL, compiled with gcc and O2. Compilation time with minimal standard library includes is ~350ms, which is not bad at all (the effect of a single
#include <bits/stdc++.h>is much greater). I chose .jpg quality level 90.Code for test
Where gradient looks something like this

And noise like this
