Raster graphics / heatmap performance

[ssfrr]

(continued from #332)

@jackparmer pointed me towards https://plot.ly/~PythonPlotBot/829, which is a good example of the sort of plots I'm working with.

On my machine (laptop without super graphics card, but 16GB ram), that page takes around 17s to load, and then clicking the "code" heading crashes the browser tab.

From chrome's profiler, it looks like there's a gap in the middle where the CPU isn't doing much, I'm not sure what's going on there.

The plots here (which are larger) load OK, but demonstrate some unexpected performance differences between the GL and non-GL

• The mouse interactions for the GL version are laggier than the non-GL one, particularly with the box zoom-selection.
• timing the loads separately (commenting out one at a time) the GL one takes about 4-5sec to load and the non-GL takes 2-3sec.
• when repeatedly re-loading the GL heatmap, it occasionally renders only the color bar, not the actual heatmap.

[jackparmer]

Thanks for reporting @ssfrr !

@etpinard and @dfcreative would know the most about what you're seeing. At one point heatmapgl plots could load 1M points in about 1s on a Macbook Pro - they may have regressed since then. There is a plan to keep an eye on benchmarks in the works here: #1511

[etpinard]

Thanks for the report.

I'm getting ~1000ms render for 1e6 points here: https://codepen.io/etpinard/pen/YQYNNd?editors=1010

I didn't notice any regressions since heatmapgl was included in the main plotly.js bundle in v.1.21.0.

---

I very impressed with heatmap's performance. I guess Chrome has made some serious performance improvements in their canvas2d implementation in the last few months.

[dy]

@jackparmer https://plot.ly/~PythonPlotBot/829 and https://jsfiddle.net/9wh2nz5z/2/ consistently crash chrome for me, every tab, not only GPU engine.

gl-heatmap2d seems to be slow by itself, regardless of plotly, here is the demo of 1e6 points. Although, comparing fps to 1e6 points before refactoring, there seems to be no regression introduced.

With experience of a couple audio-vis modules (like gl-spectrogram, spectrogram, sillyscope), should say that heatmapgl method of rendering is difficult for sustaining performance on millions of points, which spectrograms are.

[jackparmer]

Hm, maybe we should think about introducing spectrogram as its own GL trace type. It comes up often enough. MATLAB and matplotlib have dedicated spectrogram plots:
https://www.mathworks.com/help/signal/ref/spectrogram.html
https://matplotlib.org/examples/pylab_examples/specgram_demo.html

[rreusser]

I've wondered about spectrogram/fft as a transform type, though figuring out the frequency axis scaling is usually the most finicky part. Transforms modifying layouts are perhaps not the best.

[gvwilson]

Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson