-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Correctly compute path extents #16832
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
I assume this doesn't count as a "major new feature"? If it does I'll add it to |
Is the first commit elsewhere as a separate PR? If so please refer to it so that we can review things in order. |
Ooops, you're right. I got mixed up and thought it was the other way around. This depends on #16812, which in turn depends on your #14199 being merged, which I just realized hasn't happened yet. My bad. |
dd3fec7
to
24b6d39
Compare
b6ca2eb
to
ca69d46
Compare
ca69d46
to
1b12e91
Compare
692c20c
to
a98a12e
Compare
Specifically for "stacked" PRs like this I would suggest squashing them to a single or a small number of commits cleanly on the top of the parent PR (or master, if the parent PR has been merged) to simplify the review. Otherwise it's too hard for the reviewer (well, at least for me) to keep track of what's done where. |
a98a12e
to
97c748f
Compare
@anntzer Thanks for the tip! I squashed all the PRs in this "stack" into one commit each, so you can review the relevant parts easily :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments that might be useful to the reviewer.
lib/matplotlib/path.py
Outdated
@@ -421,6 +432,54 @@ def iter_segments(self, transform=None, remove_nans=True, clip=None, | |||
curr_vertices = np.append(curr_vertices, next(vertices)) | |||
yield curr_vertices, code | |||
|
|||
def iter_curves(self, **kwargs): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did try to make iter_segments work first. But I found that here (and #16859, and upcoming PR on center of mass), I kept repeating this logic across each function I wrote so that I could get all the control points of each curve, so I went ahead and added this generator.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A problem is that naively you'd thing the difference between iter_segments and iter_curves is that one returns segments and the other returns curves, but actually it's something completely different: one excludes the start point of each segment/curve and the other includes it. So should this instead be a kwarg to iter_segments, e.g. include_starts
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to make this a private helper method that is called by iter_segments
when the parameter include_starts
is passed, but I worry about bloating iter_segments
with a bunch of options.
Especially because it's really obnoxious that .iter_segments()
returns a flattened sequence of coordinate pairs, so in order to create the desired API (more importantly to not doom anyone using this code in the future to a lifetime of reshape
calls), I'd have to add another parameter as well flattened=False
which determines whether to flatten the (naturally (N,2)-shaped) array of control points before returning it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, and currently, .iter_segments()
returns a vertex that we're supposed to be ignoring (CLOSEPOLY) instead of correctly returning the first vertex of that stroke.
This is almost certainly a bug, but would probably want its own PR.
Adding the CLOSEPOLY bugfix, include_starts
and flatten_vertices
to iter_segments
instead of just making a separate iter_curves
makes the code significantly noisier, but if that's not as big of a priority as minimizing new API surface, I'm happy to do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushed up a new version where the generator yields BezierSegments and is named iter_bezier
. I think this solves the problem that you (correctly) pointed out of the name .iter_curves
not being intuitive, along with preventing me from having to make multiple, significant modifications to iter_segments
.
9dc3840
to
f0571f0
Compare
225b1f8
to
63ec774
Compare
ad22228
to
b29f403
Compare
@QuLogic, Fixed tests to follow the "parametrize" conventions I found in tests/test_axes.py. Let me know if there are still changes I could make to have the tests be more in line with the mpl conventions! |
9161982
to
b1732b6
Compare
Wow, extremely surprising defaults for But new, fully vectorized (and easier to read) version of the path extents code now pushed up, ready for re-review! |
5f689df
to
1e44dbf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These comments are not too strong.
1e44dbf
to
e0d3da1
Compare
e0d3da1
to
5f8493b
Compare
5f8493b
to
95a530c
Compare
anyone can merge postci |
PR Summary
Closes #16830 and #7184.
This code will be needed to implement
MarkerStyle
normalization correctly (building on the work now approved in #16773).Roadmap:
#16812 (*) <- (This PR) (*) <- #16859 (*) <- #16888 <- #16889 (*) <- #16891 (MarkerStyle improvements!)
"<-" means "depends on", and "(*)" marks PRs whose implementations are complete and fully ready for review.
PR Checklist