-
Notifications
You must be signed in to change notification settings - Fork 606
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
Events/Legend/crosshair is active for points outside the plot area if the plot is zoomed #997
Comments
Was able to solve this by overriding the mouseMove_ function, like so:
The trick is this line that checks if the nearest selection is within the current zoom window. |
I think this needs more thought. I consider it a good thing that once you’re past half the distance that the next point is selected. The fix is also incomplete. Looking at the crosshair:
The display of the crosshair “outside” is unfortunate… but I don’t think disallowing selection of these points is the solution. We could catch this in the crosshairs plugin and do various mitigations there:
Thoughts? |
IMO this should be fixed in Dygraph and not in the plugin, since it affects all plugins and all code that deals with Dygraph callbacks for the point past the axis. Also the reason for the point outside the axis is still opaque. My assumption was that ...
To illustrate this behavior for a time series, consider the following diagrams:
If my assumption is correct, the root cause of the issue should be addressed, and Dygraph should calculate the (virtual) point at the 0 value of the X axis and use it solely for drawing a line, without outputting the point past the axis. This would be a more effective solution than adding mitigations on top of the existing behavior. Naturally, I cannot anticipate all the potential implications of such a fix. However, to condense this: address the root cause of the issue don't add mitigations. |
andnorxor dixit:
IMO this should be fixed in Dygraph and not in the plugin, since it
affects all plugins and all code that deals with Dygraph callbacks for
the point past the axis.
Another point can be argued that plugins can decide by themselves
what they want to do with values that lie outside of the x or y or
both axēs, as their answer may differ.
I’m not deciding anything yet or something, just looking for what
options we have.
Zoomed. In this case a is needed for Dygraph draw the line on the left of point B.
Let me zoom in a bit more and draw the mouse pointer.
^ /
| /
| /
| B
| /
| /
| ↖/
|/
/|
A |
-------|------------------------> time
| ==============| visible area
In this case, point A is highlighted, not B, because the
mouse pointer is closer to A than to B. This is consistent
behaviour within dygraphs, and I played a little with this
in the crosshairs demo (since that’s the easy one to exhibit
the issue).
If there’s a change in highlighting behaviour, where midway
between B and C the highlighted point switches, but you don’t
do that midway between A and B even if A itself is not visible
then the UI becomes inconsistent and jarring.
If my assumption is correct, the root cause of the issue should be
We’re looking for what the problem (not the symptom) is and
then which root to look at, right now.
Dygraph should calculate the point at the 0 value of the X axis and use
it solely for drawing a line, without outputting the point past the
axis. This would be a more effective solution than adding mitigations
on top of the existing behavior.
You mean like this:
^
| C
| /
| /
| /
| B
| /
|/
x
/|
A |
-------|------------------------> time
| ==============| visible area
Inserting a fake point x and then highlighting this (and
switching at the midway point between A and B? x and B?)?
This is something I personally, right now without having
thought about it more than three minutes or so, would like
to never see: fake data invented.
The legend (and the crosshair) get real data points, and
never an interpolated value (modulo rollPeriod).
But, again, let’s collect options and opinions at first.
That is assuming I even understood your proposed change
correctly…
bye,
//mirabilos
--
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)
|
Steps to reproduce:
This is an edge case, but if a dygraph is zoomed in there are invisible points outside the plotArea which still fire events and influence the legend and crosshair behavior.
Those points have negative x coordinates.
Actual result
On mouseover those points fire callbacks (ex.: drawHighlightPointCallback) and are visible in the LegendFormatter. Also the crosshair will draw a vertical line outside the plot area.
Expected result
Points outside the plotArea should not fire events regarding the UI.
Possible reason
My assumption is that on a zoom level you don't get a sample at the 0 point of the X-axis but dygraph has to draw a line for this period (0 -> first visible sample), so there's a need for this sample outside the plot area but dygraph does not disable eventHandlers and callbacks for this edge case.
The text was updated successfully, but these errors were encountered: