You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Behavior of contains() inconsistent with fill in overlapping paths #32329
How do the two cases behave with contains() and mouse checking on the various artists?
I've investigated this, and amusingly enough, contains() is not fully consistent with either fill rule. The current logic (in this function) is essentially (and possibly unintentionally) consistent with the even-odd rule on any individual subpath (and if the subpath does not self-intersect, the non-zero winding rule is the same). However, if there are multiple subpaths, a point is considered "inside" the combined path if it is inside at least one subpath, even if the combined effect of all subpaths mean that the point should actually be "outside". This means:
If all subpaths do not self-intersect and do not intersect with each other, contains() is consistent with both the non-zero winding rule and the even-odd rule (that is, both rules have the same result)
If there is a single subpath that self-intersects, contains() is consistent with the even-odd rule
If there are multiple subpaths that do not self-intersect but do intersect with each other, and all subpaths are the same orientation, contains() is consistent with the non-zero winding rule
If none of the above, contains() gives a "wrong" result: it is not consistent with either rule
My inclination is that fixing contains() should be deferred to a future PR.
Here is an interactive example that shows how the existing contains() code sometimes matches one fill rule and not the other, depending on the path used for the PathPatch.
I've already verified how to modify point_in_path_impl() in _path.h to be fully consistent with one fill rule or the other. The thought needed is how to set up the (internal) API to carry the current fill rule down to that level to switch which one is being calculated.
Activity
ayshih commentedon Sep 10, 2026
Here is an interactive example that shows how the existing
contains()code sometimes matches one fill rule and not the other, depending on the path used for thePathPatch.ayshih commentedon Sep 10, 2026
I've already verified how to modify
point_in_path_impl()in_path.hto be fully consistent with one fill rule or the other. The thought needed is how to set up the (internal) API to carry the current fill rule down to that level to switch which one is being calculated.