[Bug]: inconsistency between inline and other backends (ipympl, qt)

[ericpre]

Bug summary

There is an inconsistency between backends, inline versus qt/ipympl with respect to what artists need to be included in the figure.
xref hyperspy/hyperspy#2991.

Code for reproduction

import matplotlib.pyplot as plt

fig, ax = plt.subplots()
ax.plot([0, 1])
ax.text(1.0, -500.0, 'test')

Actual outcome

Give the following error with the inline backend and works fine with the qt or ipympl backend, because the inline include the test in the figure, while the qt or ipympl backend doesn't.

  File "C:\Users\M0041User\mambaforge\lib\site-packages\IPython\core\formatters.py", line 341, in __call__
    return printer(obj)

  File "C:\Users\M0041User\mambaforge\lib\site-packages\IPython\core\pylabtools.py", line 151, in print_figure
    fig.canvas.print_figure(bytes_io, **kw)

  File "C:\Users\M0041User\mambaforge\lib\site-packages\matplotlib\backend_bases.py", line 2319, in print_figure
    result = print_method(

  File "C:\Users\M0041User\mambaforge\lib\site-packages\matplotlib\backend_bases.py", line 1648, in wrapper
    return func(*args, **kwargs)

  File "C:\Users\M0041User\mambaforge\lib\site-packages\matplotlib\_api\deprecation.py", line 415, in wrapper
    return func(*inner_args, **inner_kwargs)

  File "C:\Users\M0041User\mambaforge\lib\site-packages\matplotlib\backends\backend_agg.py", line 540, in print_png
    FigureCanvasAgg.draw(self)

  File "C:\Users\M0041User\mambaforge\lib\site-packages\matplotlib\backends\backend_agg.py", line 431, in draw
    self.renderer = self.get_renderer(cleared=True)

  File "C:\Users\M0041User\mambaforge\lib\site-packages\matplotlib\backends\backend_agg.py", line 447, in get_renderer
    self.renderer = RendererAgg(w, h, self.figure.dpi)

  File "C:\Users\M0041User\mambaforge\lib\site-packages\matplotlib\backends\backend_agg.py", line 93, in __init__
    self._renderer = _RendererAgg(int(width), int(height), dpi)

ValueError: Image size of 376x79293 pixels is too large. It must be less than 2^16 in each direction.

Expected outcome

With respect to include or not the test in the figure, the backend should behave consistently.

Additional information

No response

Operating system

Windows

Matplotlib Version

3.5.3

Matplotlib Backend

inline

Python version

3.9

Jupyter version

No response

Installation

conda

[tacaswell]

This is because as part of switching to the backend inline sets mpl.rcPararams['savefig.bbox'] = 'tight' which tries to shrink (or extend) the bounding box to fit all of the artists (this was a pragmatic fix to the issue of axis labels getting clipped that we now have constrained layout to support with a fixed output size).

The way that inline works is that it saves the figure to a buffer and then injects the base64 encoded png into the notebook in a dataurl. In the rest of the backends we use a lower level method of drawing that does not consider than rcparam.

Setting this rcparam back to None or 'standard' should make inline clip the text like the others backends, and with any backend if you save a figure with the Text way out there with fig.savefig(..., bbox_inches='tight') I would expect the same failure.

[ericpre]

okay, it sounds like that this is a desired behaviour then? Would it be worth to inform the user with a warning that some artists are clipped when this happen?

[tacaswell]

In general clipping is expected (for example if you zoom), I think we would have far more false-positives than true-positives if we started to warn.

[jklymak]

To be clear, Matplotlib isn't doing this, ipython is doing this in the in-line backend. I think the odds of ipython changing this after having this as a the default for so long. If you are doing tests you can disable this. https://stackoverflow.com/questions/26714626/how-to-disable-bbox-inches-tight-when-working-with-matplotlib-inline-in-ipytho

[timhoffm]

This is an unfortunate behavior of the inline backend. But I see no way to how we or ipython can improve the situation annoying a lot of users one way (changing behavior) or the other (printing noisy information).

Basically the only option would be to introduce a new backend name other than inline that has different defaults. This has to be done on the ipython side. But if we think this is a reasonable idea, we could lobby for it.