Skip to content
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

Fix #5475: Support tolerance when picking patches #5500

Merged
merged 2 commits into from Nov 23, 2015

Conversation

mdboom
Copy link
Member

@mdboom mdboom commented Nov 17, 2015

No description provided.

@tacaswell
Copy link
Member

why did the two contains methods go away?

if cbook.is_numlike(self._picker):
radius = self._picker
else:
radius = self.get_linewidth()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we are here, can we change the variable name "radius"? It is misleading. I would be fine with delta_r, possibly?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, I see that it is tied to an input variable... grrr...

@mdboom
Copy link
Member Author

mdboom commented Nov 17, 2015

The overridden versions of contains were specializations for rectangles and circles. Obviously, in a mathematical sense you can do a faster calculation on a rectangle or circle than in the general case of a path.

However, they aren't compatible with how the picking tolerance calculation is supposed to work, which is a distance in pixel space. In order to make them work on a circle, for example, you would have to inverse project the tolerance from pixel space to "patch space" (which is usually (-1, 1)), which could be different in the x and y dimensions in the case of scaling or projection. Rectangle is probably more easily doable, but there's also an advantage to reducing the number of code paths. It's much easier to just use the general tolerance-aware picking we already have -- it's all in C++ so even though mathematically it's more complex than the distance to the center of a circle, in practice I don't think it makes much difference.

@WeatherGod
Copy link
Member

the general polygon hit-test code can get computationally expensive as the number of vertices goes up. While I agree that for rectangles the cost/benefit isn't really there since there are only four vertexes, but circles got a lot of vertices, and they also have a very cheap geometric definition of an interior hit. I think it might be worth it to restore the circle case and add support for tolerance, even if it is a rough approximation of the tolerance.

@mdboom
Copy link
Member Author

mdboom commented Nov 17, 2015

Circles only have 8 vertices because they are approximated with Bézier splines.

@WeatherGod
Copy link
Member

But, does the C++ hit-testing code know that? Have we been hit-testing circles with octagons?

@mdboom
Copy link
Member Author

mdboom commented Nov 17, 2015

The C++ hit-testing understands Bézier curves. They are not approximated with octagons -- the Bézier curve approximation is accurate to around 0.001 of the radius, which is good enough for on-screen display most of the time.

@WeatherGod
Copy link
Member

Ok, I hadn't realized that the hit-testing code understood bezier curves (I'll have to take your word on that, I haven't looked at the C++ stuff in a long time).

So, does the code comment in the base class method make sense anymore? Should any subclass ever implement their own contains?

@mdboom
Copy link
Member Author

mdboom commented Nov 20, 2015

So, does the code comment in the base class method make sense anymore? Should any subclass ever implement their own contains?

That's a good question. I suppose they could if they could reasonably implement tolerance in physical space. In the general case that's non-straightforward, though. Maybe we just remove the comment?

@WeatherGod
Copy link
Member

That's what I am thinking. Outdated comments are as bad a broken code...

On Fri, Nov 20, 2015 at 2:30 PM, Michael Droettboom <
notifications@github.com> wrote:

So, does the code comment in the base class method make sense anymore?
Should any subclass ever implement their own contains?

That's a good question. I suppose they could if they could reasonably
implement tolerance in physical space. In the general case that's
non-straightforward, though. Maybe we just remove the comment?


Reply to this email directly or view it on GitHub
#5500 (comment)
.

@mdboom
Copy link
Member Author

mdboom commented Nov 20, 2015

Comment removed.

WeatherGod added a commit that referenced this pull request Nov 23, 2015
Fix #5475: Support tolerance when picking patches
@WeatherGod WeatherGod merged commit 00dce00 into matplotlib:master Nov 23, 2015
WeatherGod added a commit that referenced this pull request Nov 23, 2015
Fix #5475: Support tolerance when picking patches
@WeatherGod
Copy link
Member

backported to v1.5.x as 8fcbf60

@QuLogic QuLogic added this to the Critical bugfix release (1.5.1) milestone Nov 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants