There is no assert in here. What exactly should this test? Just thatget_window_extent() can be called without renderer?

The comment does tell differently. It says something about the "expected extent" and "various dpi". Both of which I don't see in the test code.

I was lazy and did not remove the comment.

Yes, the test is just that this does not raise.

So, we have lots ofget_window_extent(renderer=...) in the code base. Is it all necessary or could a lot of it be safely replaced by this? I guess I can understand for objects that don't have a reference to their figure, but in general, I think most objects know how to get back to their containing figure...

I don't think we want to always fall back to the cached renderer. There are some use-cases (such as the mixed-mode vector/raster cases where we need to be able to specify which renderer we want to be using with out having to propgate that state globally.

Ithink the mixed mode renderer is the only case where this could be a problem, right?
But in fact even for the mixed mode renderer we're not doing this correctly right now, because artist.draw(renderer) will store the instance of MixedModeRenderer as the _renderer attribute, so e.g. even if the artist was drawn rasterized, by the end of the draw the MixedModeRenderer will have reset itself to vectorized and later calls to get_window_extent() will use the cached MixedModeRenderer in the vectorized state.

That's technically a backward incompatible change (although, as I've mentioned in a previous PR doing something similar, I think this is a change that is worth making.)