Closed
Conversation
Contributor
Author
|
Investigating the 6 line difference that this caused in walmart.html, I see that because of a mix-up between offsets (the DPI offset and the hex offsets), we ended up having a different image with the DPI offset compared to without. This is a bug: while the rounding is obviously a bit arbitrary, the offset should only translate the rendering, not modify the binning. |
…ndefined (older browser), or <= 1 (actual low-res screen)
…anslation we apply on lower DPI screens
Fil
force-pushed
the
fil/refresh-snapshots
branch
from
7384d08 to
dae56cb
Compare
Contributor
Author
|
rebased |
Member
Contributor
Author
|
obsolete after #2373 |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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 defaults the snapshots (mocha) to use offset=0 (as a follow-up to #1442).
And we refresh all snapshots, which also benefit from the reduced precision in numbers (#2270, #2234)
closes #1445
Additionally, working on this revealed a bug, where the image generated when offset=0.5 was using a different origin for the hexes. As a result, the image produced was different when the DPI offset changed; two viewers using different screens would not see the same binning. The image now is the same independently of the DPI offset (but its coordinates are shifted by -0.5px and the path is translated by +0.5px). Note that the images in the test snapshots have changed, since offset=0 is now our baseline, but that's OK.
The bug is now fixed, but this reveals another issue: I've tried to create a new snapshot test that would show why we need ox=0.5 in
hexbin.js, but I can't understand the logic any more, since what we gained on the right-hand-side by having the outer hexes be "inside" the frame, we lost on the left-hand side.(A better solution would be to rescale around the center by a factor 0.999999999…? which I'm doing here #2367)