Improved hover detection for scatter plot fill tonext*
#6865
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The tests rely on scatter mocks `scatter_fill_self_next` and `scatter_fill_corner_cases` and test for a number of points that are currently not correctly detected when hovered over for tonexty and tozeroy fills.
Previous code would not correctly construct the polygons used for detection whether the cursor is within the fill region of a trace. Some of the previously created tests fail with this as the hover points in question cannot currently be correctly detected using the detection polygons.
…ests in scatter plots. However, SVGElement does not allow for an easy way to determine the positioning of the hover label, so the polygons are still in use for that.
For curved edges of fills there is a chance that the hover detection polygons miss a point and the correct hover label position cannot be determined. Previous code fell back to positioning the label at the largest edge of any polygon of the trace of their combined vertical midpoint, with undetermined behaviour if no polygon overlapped the midpoint. This change instead falls back to simply displaying the label at the current cursor position, which simplifies code and results in less confusing label placement.
…catter plot fill tonext* plotly#6865"
archmoj
added
bug
|
By the looks of it, this will likely also address #2399 of the plotly.py repo. |
lumip
changed the title
tonext*tonext*
archmoj
reviewed
Jan 26, 2024
|
Looking excellent to me. 🎖️ 🏅 🥇 |
Co-authored-by: Mojtaba Samimi <33888540+archmoj@users.noreply.github.com>
alexcjohnson
approved these changes
Jan 30, 2024
There was a problem hiding this comment.
💃 Looks great to me! tested by loading the line-shape-arrow mock and calling:
Plotly.restyle(gd,{fill:'tonexty',hoveron:'points+fills'})On this branch it looks wayyy better than on master. Every once in a while I see the hover label jump around despite me not changing which shape I'm on top of, but it's still always labeling the correct object AFAICT. Very nicely done @lumip!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hover detection (and hover label placement) does not work correctly on scatter plot fills when using
tonextx,tonexty, as demonstrated in #2165 . This is due to faulty construction of the hover detection polygons in these cases.This PR contributes the following commits to address the issue:
self,tonext,tonextyandtozerybased on test mocksscatter_fill_corner_casesandscatter_fill_self_next, paying special attention to corner cases where current hover detection fails to detect the correct trace ( 4628741 )src/traces/scatter/plot.js. However, this still results in some misdetections, especially for traces with curved edges or "jagged" shapes (e.g.shape='vh'), where the detection polygon construction will not follow the visual edge. ( be658dd )isPointInFillmethod of theSVGElementused to render the fill. This result in always correct detection of the hovered over trace. However, theSVGElementdoes not provide an easy means to compute hover label placement, so the detection polygons are still used for that. Close to curved edges, where polygons are not accurate, this can cause labels to end up in weird positions. ( 3eb4738 )This is currently still not a perfect solution but I think this has reached a reasonable state now. I'm not sure whether the change in the last commit is desired but it seemed the more intuitive fallback to me after reviewing the changes of the third commit - please advise.
Further improvements for this would likely require either fundamental improvement of how detection polygons work to accurately model edges that are not simply straight lines between trace points, or a way to use the
SVGElementto compute hover label positioning. I tried some approaches for the latter, but ultimately did not come up with a satisfying solution. I believe the current state is acceptable for the time being and a noticeable improvement over the current state.Reminder:
After opening a pull request, developer:
1010_fix.mdor1010_add.mdinsidedraftlogsfolder as described in this README, commit it and push.git push -f) to remote branches associated with opened pull requests. Force pushes make it hard for maintainers to keep track of updates. Therefore, if required, please fetchupstream/masterand "merge" with master instead of "rebase".