Fix zoom transformations to be based on display coordinates instead of data coordinates - #602
Merged
Merged
Conversation
Pull Request ReportChanges
|
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #602 +/- ##
=========================================
Coverage 49.62% 49.62%
- Complexity 6238 6239 +1
=========================================
Files 378 379 +1
Lines 37583 37593 +10
Branches 6158 6159 +1
=========================================
+ Hits 18652 18657 +5
- Misses 17701 17710 +9
+ Partials 1230 1226 -4
☔ View full report in Codecov by Sentry. |
There was a small bug in the logAxis properties invalidation listener. It updated the cached value with a method that used the cached value resulting in a nop instead of updating it with the new value of the property.
wirew0rm
force-pushed
the
fixZoomTransformations
branch
from
August 17, 2023 11:59
c05ad2f to
10d7173
Compare
ennerf
reviewed
Aug 17, 2023
ennerf
reviewed
Aug 17, 2023
ennerf
previously approved these changes
Aug 17, 2023
If the axis gets changed multiple times during event handling, but the cache is only updated during layout, axes transforms from the event handlers use outdated transformations. This has the effect that e.g. panning only applies the first mouse event in each pulse and the panning is a lot slower than the actual mouse movement. This adds a method to the axes which can be called by plugins which use and update the axis range.
Previously the zoomer would perform the scroll-zoom and panning calculations in data coordinates. This is identical to pixel coordinates for linear axes, but for e.g. log axes this leads to strange behaviour since it can result in negative data values. This changes the Pan and pan and scroll behaviour, the rectangle zoom was naturally always using screen coordinates anyway, so this should also be more consistent.
It seems that groups are not well suited to positioning nodes on top of the graph. Replacing the Groups for the Plugins by Panes fixes an issue where the zoom rectangle would shift to the upper left corner of the chart area whenever there was a relayout while a rectangle zoom was ongoing.
wirew0rm
force-pushed
the
fixZoomTransformations
branch
from
August 17, 2023 13:32
07a3168 to
e63d771
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
This branch was previously deployed
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Previously the zoomer would perform the scroll-zoom and panning calculations in data coordinates. This is identical to pixel coordinates for linear axes, but for e.g. log axes this leads to strange behaviour since it can result in negative data values.
This changes the Pan and pan and scroll behaviour, the rectangle zoom was naturally always using screen coordinates anyway, so this should also be more consistent.
To archive this a change to AbstractAxis was necessary to update cached variables on range change.
If the axis gets changed multiple times during event handling, but the cache is only updated during layout, axes transforms from the event handlers use outdated transformations. This has the effect that e.g. panning only applies the first mouse event in each pulse and the panning is a lot slower than the actual mouse movement.
Also incorporates a small fix in the pom to use valid automatic module names, converts the ErrorDataSetRendererStylingSample to a correct FxSampler sample and fixes 2 small bugs: