Description
I originally posted these comments to the plotly.js forum, before realizing that they apparently belong here. Recently Etienne wrote in the forum of the intent to speed up extendTraces, to make incremental "live" graphing much faster. Currently I measure no significant difference between extendTraces and handing all of the data every time to Plotly. At the risk of stating what everyone knows, in my work on VPython over the years I’ve done several things to speed up incremental plotting. Perhaps these comments will be useful to the Plotly developers.
(1) When autoscaling, whenever a new point requires changing the scale, change the scale by a few percent more than needed to include the new point, so that there’s a good chance that a few later points can fit without readjusting the scale.
(2) For a lines object with no markers, discard any point that would be placed within a few pixels of the most recently plotted point. I’m doing this with my use of Plotly, and it can make a huge difference. Even without major improvements for incremental plotting, it would be useful for there to be a parameter to tell Plotly to discard points instead of me having to do the discarding; after all, Plotly knows more than I do about the pixel positioning. (The reason not to do this if there are markers is that in general markers on lines are important indications of endpoints of line segments.)
(3) Provide an “interval=N” option for all types of objects, in which Plotly only adds to the plot the Nth point, discarding the rest.
Also, my situation is one where intensive computations are coupled with incremental graphing of results of those on-going computations, in synchrony with the computations and associated 3D visualizations (using VPython). Both the JavaScript computations and the graphing are of course run off setTimeout(), and the challenge is to use as big a fraction of the second as possible for both activities.
Just before executing extendTraces I set lock = true, and when there arrives a callback from extendTraces that Plotly has finished, I set lock = false. While Plotly does its work (apparently with many calls to setTimeout), computations also run when they can, generating additional graphing data which however cannot be sent immediately to Plotly. So during the time that lock is true, data to be sent to Plotly is pushed to a list, waiting for the lock to become false, at which time extendTraces is driven again from the accumulated data (and the list of pending output is cleared).
My suggestion is that in a revision of extendTraces it would be very helpful to the Plotly user to have this lock machinery embedded in Plotly itself. In other words, extendTraces would be callable at any time but would actually trigger graphing (and clear the task list) when ongoing Plotly updates were complete. This would free up the Plotly-using program from having to implement this lock machinery itself.
Bruce Sherwood