Update plots in Pluto without recreating the entire figure

[gianmariomanca]

I'm looking for something equivalent to: https://plotly.com/python/figurewidget/

This is also common in Matlab where you can create a figure and a plot and the just update the XData, YData, etc, for speed and to avoid issues with windows/figures focussing.

The idea is: it looks like rerunning the full "plot" command when changing the data is unnecessarily slow.
Having the ability of "refreshing" a plot should allow faster response times (using sliders for examples) and to create animation with for loops etc.

Is the capability already present? If so, it would be very helpful if you could point me to an example.
If not it would definitely be a very helpful addition.

(I'm looking in particular for something with the plotly backend, but I'm open to alternatives)

[gianmariomanca]

Looking at http://docs.juliaplots.org/latest/backends/
This must be related to the comment:

plotlyjs() is the preferred option, and taps into the great functionality of Spencer Lyon's PlotlyJS.jl. Inline IJulia plots can be updated from any cell... something that makes this backend stand out.

from

I have not tried it yet in Jupyter, not sure how/if it applies to Pluto.

[fonsp]

I ran some experiments with updating data in plotly instead of rerendering the entire figure, but the performance benefit seemed to be negligable.

Experiments:
https://github.com/fonsp/disorganised-mess/blob/main/very%20fast%20plotly.jl
https://github.com/fonsp/disorganised-mess/blob/main/very%20very%20fast%20plotly.jl

Note that plotly in Pluto is currently quite slow because we have to create a new iframe for every new output. In my first experiment, placing the plotly DOM directly inside the cell output caused a huge performance increase. Later experiments to partially replace data did not have a significant effect.

[gianmariomanca]

Ah nice. Sorry I just noticed this comment, not sure why I didn't get notifications. I'm not familiar enough with the ecosystem to follow the details at this stage, but based on your learnings should be "placing the plotly DOM directly inside the cell output" the default (user friendly, behind the scenes) behavior since it's so much faster? Which part of the ecosystem should change for that to happen?

The use cases I have in mind that you have some signal processing pipeline of data coming live from a sensor and you want to do live data visualization (1d / 2d heatmap / 2d surface). This normally requires a reasonably high refresh rate for it to be a pleasant experience (same thing if the data is recorded and you want to explore it). You're examples might be fast enough by looking at them, I could not really tell yet. I'll play a bit more with them as soon as I get a chance.

Plotly being interactive is quite useful for data exploration, since you can imagine finding an interesting "frame", pausing and still having the plotly interactivity, to zoom, hover, rotate, etc.

Having said that, could other backends have other advantages for these kinds of data explorations as far as you know?

[gianmariomanca]

PS I also just realized that in your example I cannot really have a cell that is "running the pipeline" and updating the plot in a different cell (or in the same cell). Is my understanding correct?
Imagine having a for loop in a cell (creating random data, reading from a file or a sensor) and updating the plot for each iteration (maybe with the appropriate pause to reduce the frame rate to if we want to reproduce a fixed frame rate with recorded data).

[fonsp]

Is my understanding correct?

That's right, this is currently not possible in the execution model of Pluto. You could try to rewrite your problem to make it work, for example using a clock, or you can precompute all results, and use a slider to explore them: https://gist.github.com/fonsp/971666be05d34bfc1254d69756ac3b1f

[gianmariomanca]

Just adding some (related) links for future reference:
JuliaPlots/Plots.jl#3559
https://discourse.julialang.org/t/pluto-plots-with-plotlybase-plotlyjs-with-working-static-html-export/61730/10