You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR #2527 introduced a 'draggedPts' trace category (see #2527 (comment)) which was later deemed a potential overkill by @alexcjohnson in #2527 (comment) to make the pan hot code path avoid large .selectAll() (which can be very slow).
What we should try to do instead is: stash those points selections (probably in fullLayout._plots[subplotId]) early (probably during the trace plot step) and use them directly in pan (and scroll?) hot code path.
The text was updated successfully, but these errors were encountered:
While doing this, we should investigate ways to remove more things from that hot pan code path like various fullLayout._has return values (mentioned here).
Moreover, we could perhaps improve performance even more by combining Drawing.setScale and Drawing.setTranslate into one method (ref).
PR #2527 introduced a 'draggedPts' trace category (see #2527 (comment)) which was later deemed a potential overkill by @alexcjohnson in #2527 (comment) to make the pan hot code path avoid large
.selectAll()
(which can be very slow).What we should try to do instead is: stash those points selections (probably in
fullLayout._plots[subplotId]
) early (probably during the trace plot step) and use them directly in pan (and scroll?) hot code path.The text was updated successfully, but these errors were encountered: