-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Avoid single_path_optimization if offsets are non-zero #16517
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Perhaps do a test like given in #16461 but settings x/ylim so that in the correct case the entire patch is out of bounds, but would be drawn at (0, 0) otherwise, and then check_figures_equal() against an empty plot? |
That worked well - the test I've added fails on current master but passes here. |
If we need to change baseline images (especially non-hexbin-related ones) I'd really rather just go with #13696 -- this bug has apparently been present for a long time, I'm not convinced it's RC to have it fixed in 3.2. Or if it helps I can make VectorTransform public in #13696; I don't like it but it's not the end of the world. |
Agree with not needing to put this in 3.2. Won't the baseline images have to change anyway at some point though? |
I don't think so. I think (not 100% sure?) here you disabled single_path_optimization when offsets are nonzero, but they really only need to be disabled when offsets are nonzero and offset_position="data". When offsets are nonzero and offset_position="screen" (which will always be the case after #13696), the old baseline images are still fine. |
b09de74
to
87b0b08
Compare
Ah yes, true - I can check for offset_position = 'data' here and not worry about the baseline images then. Surely going through either of the two code paths should give identical results, but it doesn't look like it does because the images have changed. I guess the question is for offset_position = 'screen', which code path is doing the right thing? |
87b0b08
to
487fc05
Compare
Basically single_path_optimization is slightly "wrong", because it "rounds" the markers to the closest pixel (it's fundamentally the original reason I wrote mplcairo...), see e.g. #7233. |
Co-Authored-By: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
So this is replaced by #13696? |
I think so? feel free to reopen if not. |
This is a stopgap to fix #16461 - I am guessing this is made redundant by #13696, but is a simpler fix and probably easier to get into 3.2.0.