This could well be correct, but how did you test it? In particular, did you test the performance aspects? Thanks!

This could well be correct, but how did you test it? In particular, did you test the performance aspects? Thanks!

I tried with a simple plot and plots made with subplot2grid. Showing the animation in real time or saving the video. With subplot2grid I tried configurations with figures using rowspan and figures using colspan. The colspan figures share the x axis, which is also moved by the animation.

Both simple and subplot2grid works well, with a general result similar to the current matplotlib code. The only different is "old" code is not showing labels in the axis in move while the "new" code show labels and update the label correctly.

The "old" code also have problems if the window is moved while the animation is on. While normally there is no labels, the labels for the animation frame in use are printed when you drop the window with the mouse. These labels not dissapear with the next frame. If you move the window several times the axis start looking horrible, with different labels on top of each other. With this PR is not happening, the labels still changing and updating not matter if you move the window. If necessary I can make a little video to show the problem, in the case you don't understand what I am triying to say.

About the performance as far I can test seems the same as the "old" code. Running directly on python with my data is running ok but maybe not flawless, but I think is normal. Saving the video the result run perfectly fine. For both cases the result is the same with or without the PR. Also the production time for the video is the same with or without the PR. I am using Debian. The majority of the test were using my production environment with Anaconda and Python 3.7 or 3.9 and thus matplotlib 3.4. What I tried with matplotlib current main branch looks fine too but i didn't make to many test compared to 3.4.

This code path does not affect saving (we, for better or worse) always fully render each frame when saving.

One thing to keep in mind is that text is frequently the most expensive thing to draw so if you are changing the ticks etc, the benefit of blitting may be minimal (which is obviously a generalization and breaking rule 0 of performance tuning which is benchmark first, then talk).

While this works, it is adding a bunch of duplicate work. I think the right fix here is either to sort out how to extend the boinding box grabbed for the Axes to include the decorations or to remove all of the per-axes logic and just do it at the figure level

(PS sorry for the long delay between the line comment and this comment...things came up and this sat un-sent for the last 6 hours!)

Part of the extensive logic in there is trying to figure out the right time to save the background for blitting and making sure things are "clean". I wonder if that's not quite hitting the right time.

I've popped this to draft until the architecture can be sorted out. I'm not understanding how blitting the whole figure is any different from redrawing the whole figure, in which case you may as well not blit. I thought the point of blitting was to avoid the costly axes spine and label redraw steps, and just change the artists inside the axes, which are usually cheaper. If you are changing the spines and labels, then obviously you can't save those expensive steps. I would assume that for cases where you only change the interior of the axes, this PR has made thingsfar slower.

So this would need performance proof, with reproducible examples that are shared that a) it works for the new examples and b) that it does not slow down pure blitting examples.

Getting the image on the screen is a two(+) step process:

1. we render a raster image
2. we copy the raster into the surface of a GUI widget
3. the GUI framework does what ever it does to eventually light up the pixels on your screen

Where the speed in blitting comes from is that we can cache a big fraction of the work (this is thecopy_from_bbox part) that has everything that doesnot change between frames so we can then only pay the cost in (1) for re-drawing what has changed.

I've pushed this to future releases because re-reading this I still think that while expanding the space of what gets re-drawn to possibly include the tick labels is useful, it needs to be done more surgically / in a opt-in way or the whole management scheme needs to be updated.

@ManuRS are you still interested in working on this?