-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Faster trace visibility toggling #2837
Conversation
- DRY scalar-to-array repeat option logic - DRY get-viewport logic - build scene viewport and range option once per scene (not per trace)
- so that gl-based trace can call their plot methods w/ an empty array of traces and just work. - this makes restyle(gd, 'visible', false) work properly for scattergl traces
... to plot toggle scattergl 'visible' w/o having editType 'calc', and hence w/o having to rebuild to scene options from scratch.
- to not have to guard against visible!==true traces in _module.style - to shortcut full list of modules in other places downstream
} | ||
} | ||
|
||
Plotly.plot(gd, fig).then(function() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is broken on master, consider this a bug fix.
Love the concept! But it looks like autoranged axes aren't updated with the faster logic. I'll hold off reviewing until that's sorted out as I suspect it's going to be a bit involved - likely by maintaining separate |
... and looks like we don't have any tests covering these cases 😑 |
Abandoned. See #2860 |
... by changing
visible
from a 'calc' to a 'plot' edit type and using a "visible batch" in the scattergl code, similar to how selections are currently handled.Graphs will slow calc steps will benefit the most. For example, on a 1e6 scattergl graph,
clocks in at about 30ms which is about 50x faster than on master 🐎
Eventually, we could augment this PR by adding a new edit type that would bypass
drawFramework
andinitInteractions
(which are very 🐢 for sploms), but I'll leave that for later if ok.Note that commits 3790734 and b816a8e might be a bit controversial and may have some side-effects during subplot/trace removal the spli through our tests, so I wouldn't mind a second opinion there.
I would appreciate if @dy could take a look at e85725a and cf65abd
To be merged in #2823
cc @alexcjohnson and @dy