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

Normalize zoom speed and wheel behavior across trace types #2041

Merged
merged 6 commits into from
Sep 29, 2017

Conversation

rreusser
Copy link
Contributor

@rreusser rreusser commented Sep 28, 2017

This PR attempts to normalize mouse wheel behavior across cartesian plots as well as gl2d and gl3d trace types. In particular, it:

  1. multiplies the default zoom speed of gl plots by ten in order to get them more inline with non-gl plots
  2. makes zoom speed configurable through layout.zoomspeed (should this be a config parameter?) Edit: no longer configurable; just faster
  3. removes logic that prevents mousewheel zooming while gl plots are in pan mode (corresponding to analogous svg behavior, which does not block mousewheel zoom in pan mode)

@@ -1332,6 +1332,7 @@ plots.purge = function(gd) {
delete gd._transitionData;
delete gd._transitioning;
delete gd._initialAutoSize;
delete gd._transitioningWithDuration;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was just one minor cleanup tweak I noticed along the way.

Copy link
Contributor

Choose a reason for hiding this comment

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

Good catch 👌

Copy link
Contributor

@etpinard etpinard left a comment

Choose a reason for hiding this comment

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

Looking good. Thanks for doing this @rreusser 🎉

@@ -262,34 +262,27 @@ function createCamera(scene) {
var lastX = result.lastPos[0],
lastY = result.lastPos[1];

switch(scene.fullLayout.dragmode) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this gone? fullLayout.dragmode: false should still be a thing.

Copy link
Contributor Author

@rreusser rreusser Sep 28, 2017

Choose a reason for hiding this comment

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

From what I can tell, dragmode: false isn't an option, is it? If I set that, it defaults to zoom. This is removed for a slightly different reason though: because the dragmode should not be affecting mousewheel behavior at all.

Copy link
Contributor Author

@rreusser rreusser Sep 28, 2017

Choose a reason for hiding this comment

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

Ahhh possible bug…… 🕷

When setting dragmode: false with gl3d, dragging is disabled but gd._fullLayout.dragmode = 'zoom'. That suggests it's sanitizing it but using gd.layout.dragmode instead of gd._fullLayout.dragmode. Actually setting dragmode: 'zoom' behaves correctly.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Looks like we only support layout.scene.dragmode: false (ie 3D), not layout.dragmode: false
@rreusser good catch that this should not be disabled in zoom mode anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, I see. It inherits false from layout.dragmode despite layout.dragmode: false not actually being a valid default. I'm okay with that.

Copy link
Contributor

@etpinard etpinard Sep 28, 2017

Choose a reason for hiding this comment

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

Oopppppppps, that line is in gl2d/camera.js (i.e. NOT gl3d). Funny that thing has been there since v1.0.0.

🔪 🔪 🔪 🔪 🔪 🔪

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah. Definitely undesirable. 😄 🔪

Copy link
Contributor Author

@rreusser rreusser Sep 28, 2017

Choose a reason for hiding this comment

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

(next most glaring thing, as briefly mentioned to @alexcjohnson is double-click to revert zoom to autoscale, which is the top top top thing that always gets me about scattergl plots.)

Of course not sure the meaning/relevance once regl comes through, but still seems right given the relatively low effort involved for these tweaks.

Copy link
Contributor

Choose a reason for hiding this comment

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

which is the top top top thing that always gets me about scattergl plots.)

No need to waste time on this. Double-click will just work after @dfcreative 's #1869

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Works for me. Should have bothered to do it long ago, but I'm content to wait for #1869. 🎉

scene.relayoutCallback();
break;
}
var scale = Math.exp(scene.fullLayout.zoomspeed * 10.0 * dy / (viewBox[3] - viewBox[1]));
Copy link
Contributor

Choose a reason for hiding this comment

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

@@ -1332,6 +1332,7 @@ plots.purge = function(gd) {
delete gd._transitionData;
delete gd._transitioning;
delete gd._initialAutoSize;
delete gd._transitioningWithDuration;
Copy link
Contributor

Choose a reason for hiding this comment

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

Good catch 👌

@alexcjohnson
Copy link
Collaborator

Nice, definitely better parity this way. Playing with it now though, I wonder if something a little slower (maybe half this speed?) might be best for both versions. I still think you're right not to have it configurable though.

Also, we decided long ago that 3D should have scroll zoom on always, but for SVG you need to have config.scrollZoom: true to enable it. Seems like gl2D should respect this as well, right?

@rreusser
Copy link
Contributor Author

Mousewheel speed is a contentious issue. I'd support half speed for all. They at least felt same-ish
to me with these numbers. 🐭

Can you clarify the last point? For me when scrollZoom: false,

  • scatter: no mousewheel zoom
  • scattergl: mousewheel zoom
  • scatter3d: mousewheel zoom

@alexcjohnson
Copy link
Collaborator

Can you clarify the last point? For me when scrollZoom: false,

  • scatter: no mousewheel zoom
  • scattergl: mousewheel zoom
  • scatter3d: mousewheel zoom

I think scatter and scattergl should match, but scatter3d should have wheel zoom enabled always.

@rreusser
Copy link
Contributor Author

Okay, I've 1/2'd all zoom speeds (including svg, which previously wasn't affected by this PR) and scattergl now obeys config.scrollZoom.

@etpinard
Copy link
Contributor

I think scatter and scattergl should match, but scatter3d should have wheel zoom enabled always.

👍 for me here.

But, I think in v2 all subplot types should obey scrollZoom. Moreover, I think should add a corresponding layout attribute as people might want to turn on/off scroll interactions via a relayout call. Thoughts?

@rreusser
Copy link
Contributor Author

rreusser commented Sep 28, 2017

Agreed. Including gl3d. I actually rather dislike scrollZoom being a config parameter. I find embedplot, for one, suddenly has dramatic scroll interactions I never saw when developing the plot.

@etpinard etpinard added status: reviewable bug something broken labels Sep 28, 2017
@etpinard etpinard added this to the v1.31.0 milestone Sep 28, 2017
@rreusser
Copy link
Contributor Author

Okay, I'm now content with this. Had to fix test values. The big change is cartesian zoom speed *= 1/2. Which doesn't seem all that noticeable because of inertia. A much bigger change is gl zoom speed *= 5.

@alexcjohnson
Copy link
Collaborator

💃 from my side. I have more thoughts about scrollZoom but we can discuss that more in the v2 issue #420

@etpinard
Copy link
Contributor

@rreusser what about those scroll factors. Looks like cartesian, gl2d and gl3d all use different one. Is that why you didn't bother putting them in a constants.js file?

@rreusser
Copy link
Contributor Author

rreusser commented Sep 28, 2017

@etpinard Yes. I debated whether to copy the zoom factor logic. gl3d, for one, takes for granted that the window height is actually relevant:

-camera.zoomSpeed * flipY * dy / window.innerHeight * (t - view.lastT()) / 100.0;

Perhaps that should be modified to use the plot height and conform to the same math as SVG.

@etpinard
Copy link
Contributor

Perhaps that should be modified to use the plot height and conform to the same math as SVG.

No need. I was just curious why my comment didn't get addressed.

I'm happy with the current state of this PR 💃

@rreusser rreusser merged commit 2f2b300 into master Sep 29, 2017
@rreusser rreusser deleted the normalize-zoom-speed branch September 29, 2017 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug something broken
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants