Performant, interactive Plots.jl backend for jupyter notebook

jupyter
glvisualize

#1

I’ve been using Plots.jl with plotlyjs() for interactive plots and automated ‘report’ generation. I appreciate the work that’s gone in to Plots.jl and PlotlyJS.jl - I use them every day!

Some of the individual plots have performance issues in the generated html files, so I play tricks like resampling my data (thanks to DSP.jl) and plot at lower sample rates, etc. But even at lower rates, with multiple plots, the generated pages and the interactive javascript can become rather slow.

For the curious, one of my data signals is typically 8M points, and for plotting I will usually resample to around 200k points. With spectrograms and multiple time series on multiple plots, that’s enough to slow things down on my relatively powerful desktop machine.

I know of GLVisualize.jl and know that it’s a work-in-progress backend for Plots.jl. Will GLVisualize.jl use WebGL, or something else, to render interactive plots in a more efficient way than relying on javascript to do all the heavy lifting?


#2

You should check out Makie - http://makie.juliaplots.org/stable/
It’s the future of GLVisualize, and I believe @sdanisch (the primary developer) intends for this to end up replacing Plots, providing the same functionality (backends, recipes, terse syntax) in pure julia.
It’s particularly focused on interactivity but still in a relatively early stage of development (first release coming up soon).


#3

@standarddeviant: I had the exact same problem, and that’s why I developped InspectDR:

InspectDR: https://github.com/ma-laforge/InspectDR.jl
Gallery: https://github.com/ma-laforge/FileRepo/blob/master/InspectDR/sampleplots/README.md

  • 200k points is only considered a "moderate" dataset for InspectDR. With 200k point, you still get very good interactivity with almost no lag when you drag plot data around in order to pan the plot & alter its limits.
    • You might want to bypass the Plots.jl module if you really need speed for automated ‘report’ generation, though.
  • Plot times are still good even when datasets are even larger (ex 2Gb datasets).
    • Again: You should bypass the Plots.jl (use InspectDR directly) if you want to minimize plot times.

Conditions

  • Performance is even good on a 7yr old computer running a VM session.
  • InspectDR runs at optimum speeds when the x-axis data is sorted in increasing order.

Caveat

  • Does not support 3D plots.
  • Performance is better if Plots.jl is bypassed (InspectDR used directly).
  • Not directly interactive in Jupyter - but static plot images are supported (.png works best) & you can still launch the Gtk GUI to get the interactive mode.

I myself am looking forward to GLVisualize/Makie, but last time I checked, it is not yet able to do what I needed… But I am looking forward to the first release as well.


#4

Yes, should have pointed out inspectdr as well.


#5

Thanks @mkborregaard - I will keep a watch on Makie.jl.

Thanks @MA_Laforge for writing InspectDR! I’ve used InspectDR as a Plots.jl backend, but will look at direct usage.

Is InspectDR doing something similar to to the Python package “datashader”?


#6

@standarddeviant: Thanks for pointing me to datashader - I was unaware of this package.

To a certain extent: yes, InspectDR does something similar to datashader is doing:

  1. It performs a reduction of the data for each zoom level, parsing the entire dataset each time.

    • It only “downsamples” the data for that particular zoom level… so the intent is to never drop data points (As long as we have a line plot - not a scatter plot).

    • Data reduction is simply used to minimize the commands sent to the (slower) drawing subsystem.

Differences:

  1. Data reduction in InspectDR is much less flexible than datashader - especially with scatter plots.

    • InspectDR does not do fancy/customizable normalization of pixel intensity, etc… because it is optimized for line plots, not scatter plots.
  2. It sounds like the datashader algorithm might even be faster than the one in InspectDR (time per # of points), but I have not verified this.

NOTE

  • There are probably other differences, but I don’t understand datashader well enough… and I have not had a chance to study the algorithm they use.
  • I might eventually want to make use of datashader from within InspectDR… but I probably should see if there are licensing issues with this before I start (I am not quite certain what its license entails).