Thx for the feedback @mgeier - indeed that last point is the reason why we never made it the default. It's very, very easy for unsuspecting users to end up with gigantic notebooks that make the browser completely unusable b/c there's a huge SVG in memory. The PNG backend may not be as pretty, but its file sizes are pretty well bounded by image size.

I'm curious from folks in the matplotlib team (cc @tacaswell et al.) if there's any news on this front that might change our calculations. Also, to be fair - the above was based on tests from a long time ago. I haven't done (and can't do right now) careful tests with large SVGs in JupyterLab, to see how it behaves. Maybe its more modern lumino engine can cope with this better than what we had in the past and it's worth revisiting?

In summary - if the performance pitfall situation has improved, I'm happy to reconsider our defaults. But if that's not the case I'm more reluctant: a default behavior that under 'normal' use can render the system unusable for users in hard to understand way is not a great choice, IMO.

I think that adjusting the inline backend to generate a 1x and 2x resolution save of the figure and use the image set functionality of html (if this even works with the dataurl scheme) is the best way to get higher resolution figures out of the box with matplotlib-inline.

The downside of this would be a step up in the size of the notebooks but more importantly in the time it takes to render. It might be better to always save at 2x resolution as if it was on a high-dpi display and then make sure the html will keep in from being double sized on a low-dpi display.

I think that the analysis that the SVGs can randomly become very large still holds up. Even if the upper limit for "do not crash the browser" is higher, given the rise of jupyterhubs another aspect that comes in is how much data actually gets sent to the client. A surprise 1GB svg is annoying on a home/office connection but catastrophic on a metered connection!

Excellent point re. data transfer, @tacaswell - that was another one we'd discussed in the past, but I forgot to bring it back to the table...

One of the advantages of working in hubs is the idea of "move the computer to the data when the data is too big to move to the computer", and you use the browser as a "screen-sized window" into your data/workflow. Unfortunately a surprise huge SVG can upend that assumption by trying to actually send you your data, under very normal work patterns.

As much as I like using SVG, I think I have to agree with y'all: PNG is not the prettiest but the safest option, and therefore it should stay the default. I'm going to close this issue.

But just for future reference, in case somebody stumbles upon this issue later:

I think I can live with using PNG plots during the exploration phase (where I might use one of the interactive backends anyway), but when publishing notebooks, I do want to have SVG plots (given that I'm aware that the file sizes have to be monitored, and that I can use rasterization if necessary).

I'm using nbsphinx for publishing (I'm obviously biased regarding that) and I've documented how to get my SVG (and PDF!) plots in the final HTML: https://nbsphinx.readthedocs.io/en/latest/code-cells.html#Plots
This also works for PDF output: https://nbsphinx.readthedocs.io/_/downloads/en/latest/pdf/

I've also updated my pamphlet about the Matplotlib inline backend: https://nbviewer.org/github/mgeier/python-audio/blob/master/plotting/matplotlib-inline-defaults.ipynb (previous version: https://web.archive.org/web/20220903114803/https://nbviewer.org/github/mgeier/python-audio/blob/master/plotting/matplotlib-inline-defaults.ipynb).