-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
[Bug]: Nondeterminism in SVG clipPath element id attributes #27831
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
Comments
Good first issue - notes for new contributorsThis issue is suited to new contributors because it does not require understanding of the We do not assign issues. Check the Development section in the sidebar for linked pull If something is unclear, please reach out on any of our communication |
I agree with the analysis. We need a way to uniquely identify the clip paths within a single rendering (so that we only write the clip path once and can reuse it by reference). Options that won't work:
I think the right path here is to add an additional bit of state tracking that maps (clip)paths to a monotonically increasing integer. We would then use that integer in the self._clip_path_count = defaultdict(lambda c=count(): next(c))
....
clip_id = self._clip_path_count[clippath] may too cute, but I think would work. It looks like we set up all of the state in This needs tests, both of the determinism (see the existing determinism tests for how to get the test suite do to that) and that we continue to correctly re-use paths. These tests cases should also be extended to the pdf/ps tests to make sure we do not have the same issue with non-rectangular clipping there. Finally, in addition to the polar case, the determinism tests should probably include one of the complex clip demo examples and something with multiple clip paths (a 2x2 grid of axes each with fun clipping would work). Marking as good first issue as fixing this will only require touching a small section of the code and does not have any API implications, but medium difficulty as it requires a good grasp of OO and understanding a relatively complex implementation. |
Hello, I would like to work on this issue if it's not entirely finished! I noticed that it's still open. |
I missed this quoted part of the task description previously; it seems important, but I'm not familiar enough yet with |
@tacaswell could you clarify what the 2x2 grid-of-axes test coverage should do? I think I have #27833 nearly ready to bring back out of 'draft' status, but haven't yet implemented this test. |
I had the image from matplotlib/lib/matplotlib/tests/test_artist.py Lines 100 to 124 in 4cbef2d
I suggest looking at |
Uh oh!
There was an error while loading. Please reload this page.
Bug summary
Hello - I'm trying to make the
astroplan
documentation build reproducibly in Debian, and have found a snag: despite configuring thesvg.hashsalt
to successfully makepath
identifiers in some SVG plots generated bymatplotlib
deterministic, there is a remaining problem thatclipPath
identifiers are nondeterministic.The cause appears to be the use of Python object ID (via
id(...)
calls here) when generatingclippath
IDs.Code for reproduction
Actual outcome
Differences appear in the
clipPath
identifiers and their references from elsewhere in the SVG output.Expected outcome
When an
svg.hashsalt
value is configured, the SVG output should be deterministic.Additional information
This could arguably be an enhancement request rather than a bug.
Configuring a static
PYTHONHASHSEED
value does not help to produce deterministic results.Operating system
Debian GNU/Linux (trixie)
Matplotlib Version
3.6.3
Matplotlib Backend
TkAgg
Python version
Python 3.11.8
Jupyter version
N/A
Installation
Linux package manager
The text was updated successfully, but these errors were encountered: