Round pixel snapping to actual next pixel #7465
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I don't understand why there's a + 1 here, but it rounds up to the next-next pixel instead of the next pixel. This makes images extend past the end of the frame. Fixes matplotlib#6773. Fixes matplotlib#7350.
The pixel snapping in these images moved them outside the Axes frame, or in such a way that doesn't quite align with the ticks.
I can't say for certain, but they don't look any worse. Probably the last row/column was overlapping the Axes frame and was invisible before now.
bb05c12 to
c8191a8
Compare
c8191a8 to
d0a40c9
Compare
|
Since this includes specgram tests that @tacaswell simplified greatly, ping @matthew-brett in case there are any issues with them on 32-bit systems. |
dopplershift
approved these changes
Nov 21, 2016
efiring
approved these changes
Nov 21, 2016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is hopefully a simpler alternative to #6776 (@mdboom). I don't fully understand why the rounding-to-next-pixel uses
int(ceil(width + 1)); switching toint(ceil(width))works just as well, though unlike #6776 (which only special-cases non-standard Axes), it does have an effect on our test images. An unfortunately large number of our test images are changed, though several of them for the better.I split up the test images updates into definitely-good (images were originally outside the Axes by one pixel), probably-good (images were probably on the Axes frame, but aren't any longer) and I-have-no-idea (basically all the mlab plots, which do something really strange.)