Hmm, for some reason.Artist.get_tightlayout doesn't resolve..Artist.get_window_extent does no problem.

I think that for internal calls, if we have the renderer we should pass it through rather than relying on the cache to implicitly pass it to something deep in the call stack if it is needed.

I think that for internal calls, if we have the renderer we should pass it through rather than relying on the cache to implicitly pass it to something deep in the call stack if it is needed.

Maybe? However, a lot of the time we are only fetching the renderer to pass it through.

Would it be possible to usefig.canvas.get_renderer() everywhere? It seems like theget_renderer() call should handle the caching if it can.

@greglucas I think that's what the newfig._get_cached_renderer does (if it needs to)?

The point here is that all the artists know what their figure is, so if they need the renderer, they can just ask their figure for it. However, it seems a considerable simplification not to ask users to get the renderer.

Changed the name to_get_renderer

Marking as "Needs discussion" because I think there are ideas to go the other way here and make Artists more independent of the figure. I guess if that is really going to happen, then we should think about this. But I'm unconvinced the piping necessary to make Artists portable between figures is worth the considerable complication.

@tacaswell I doubt I can attend the weekly meeting (travelling), but feel free to discuss this and decide whether we think we willreally ever disentangle artists from the figure that owns them.

FWIW, note that right now some artists can end up being drawn without knowing who their parent figure is, e.g. thePathClippedImagePatch.bbox_image attribute in thedemo_text_path.py example (try printingp.bbox_image.figure at the end of the script, for example).

Perhaps we may consider that a bug and state that if you set up artists manually, it is your responsibility to make sure that they know their parent figure, but that would probably need to be documented.

I guess I'd consider it a bad idea that when we add them to the figure they do not get the figure info added to them. But we can do that at the add_artist time.

FWIW, note that right now some artists can end up being drawn without knowing who their parent figure is, e.g. thePathClippedImagePatch.bbox_image attribute in thedemo_text_path.py example (try printingp.bbox_image.figure at the end of the script, for example).

Perhaps we may consider that a bug and state that if you set up artists manually, it is your responsibility to make sure that they know their parent figure, but that would probably need to be documented.

Following up on this, yes, I think this is a bug. The example even says that the results are dpi dependent - I don't understand how this is even supposed to work if the artist doesn't know its figure.

Sure. If you don't want to fix that example here, can you open a separate issue to track that problem? I think we also need to state explicitly somewhere in the docs (and changelog) that artists must have their .figure attribute set.

I take it back about that being a bug. Whether an artist has a parent figure or not depends on the artists, as you point out. This PR doesn't really worry about that - it is not trying to force all artists to not require a renderer for their get_window_extent, its just trying to make the argument optional for those artists that already have enough info to not need the renderer.

In the example you provided of BboxImage, it requires a renderer, and indeed in the fallback in BboxImage doesn't work (it callsget_figure() which returnsNone). I imagine the same problem occurs for any Artist not directly added to an Axes. I don't think this PR makes the situation any worse (you can still always pass a renderer to get_window_extent), and still simplifies things for most artists.

Note that the layout managers, where the extents are mostly used internally, won't drill down beyond the artists in the axes. Downstream libraries don't need to use this simplification if they don't want (they can continue to pass the renderer). The only disadvantage is a bit of inconsistency for users knowing whether an artist needs the renderer passed or not. However, most folks asking for the bbox are presumably doing something semi complicated, and should be able to handle the inconsistency (or just always pass renderer if in doubt).

My understanding of how we got here is:

• some operations on someArtists do indeed require a live renderer. However not all artists actually need the renderer
• in some of those methods the renderer was required and in others it was optional and tried to grab a cached one from someplace
• this centralizes all of the caches in one place and makes the renderer optional all the places

I think that the source of the bugs here was thatanything was accessing a cached renderer and my instinct would be to go the other way and try to remove the cache ("There are are two hard problems in computer science: naming things, cache invalidation, and off-by-one bugs"). However, it is probably too late for that (as we have long had the cache and it is useful even if it gives the users a foot-cannon) so centralizing it is a net good, however we should view this cache as for the users not for us to use internally. I think it is much better forusers to use our cache rather than keep their own cached renderer (which is definitely going to go out of sync because we do not know about it to invalidate it).

One thing done in this PR with I'm very 👎🏻 on is to then rely on this central cache for internal operations. I think it bakes too many assumption that a (should be optional) cache isdefinitely there and that the reverse connections up the Artist tree are there. I am also concerned that this is a private method so that down-stream library should probably not use it.

On a bit of a philosophical note, mpl as three layers the chrome on top (plt.plot /ax.plot /fig.subplots() / etc ) that are basicallyArtist factories, a middle layer which is theArtist instances which holdbuckets of state, and then thedraw method + renderers that produce an output that someone outside of mpl knows what to do with. Part of the state theArtsits hold is the actual data, part of the state is how to visualize it (which we specify via the class of the instance), part of the state is any "styling" like color, line style, ... (which really should be thought of as data but for another day), part of the state is some intermediate transformation (e.g. norms and colormaps for ScalarMappables), part of it is the "data to display" transformations, and part of it is a hierarchy of Artists. Many (if not all) of our difficulties come from the fact that we tend to mix up all of these kinds of state and that various parts of the library "know too much" about other parts. Because they know too much we eventually start to rely on that knowledge which leads to very brittle cross connections in the code base.

I think the medium term program we are currently engaging in is to start to tease apart all of this state into parts that are clearer and easier to reason about. One place where we get ourselves into consistent trouble is that we have lots of circular references:Figures know about theirAxess andAxess know whatFigure they are in and so on through the entire Artist tree. However, I am not 100% sure that we actually need the back references! Taking a look at where else we actually useArtist.figure it is mostly in the picking logic and accessing the figure transforms / dpi. It does not look trivial to eliminate the back reference right now, but it at least looks plausible. I would very much prefer that we do not further bake in the that these back connections exist (which, fair, they do) when we have an option not to.

I think that we should not change the signature of any of the methods, but allowNone to be passed in to mean "go get the cached one if you can". I am slightly skeptical of this step being able to create and cache a renderer andvery skeptical that we want to be relying on the cache when we have access to the actual renderer already.

The arguemnet here is is it "simpler" to do

deffoo(obj):a=obj.a    ....my_obj.a='a'foo(my_obj)

or

deffoo(obj,a):    ...foo(my_obj,'a')

I would argue that in cases where.a exists only to smuggle inputs intofoo (rather than being something inherent about the data model ofobj) then the second case is clearer and more explicit.

In this case I have the position thatArtist.figure is not an inherent part of theArtist and failing that, a cached renderer is not an inherent part of what aFigure is, thus anyplace we need a renderer, it should be required in the signature (with an option of "do what I mean" API of takingNone for users to opt-into caching).

Thanks@tacaswell for your thoughts.

This PR does two things:

1. makesrenderer and optional kwarg for all ofget_tightbbox andget_window_extent calls in the library. If not passed, we try and access the cache, if the renderer is needed at all (its usually is not). My read is that you are OK with this as a public interface?
2. it removes the renderer calls in_constrained_layout and_tight_layout. I don't see that any other internal code is changed. I can easily back this part out, I just was considering it as eating our own dogfood, rather than an important part of the PR. It also simplifies snaking renderer through a bunch of calls, but that really doesn't matter a lot, and indeed is maybe microscopically faster to only call get_renderer once.

So far as we can tell, we only explicitly needrenderer for text items, we have no idea how big they are until we render them.

WRT whether we should stashfigure on artists, so far as I can tell we already stash figure information on artists via thetransform attribute. I think that as long as we do that, we should also explicitly add the figure. In general, I think trees are much easier to use if children know their parents. If you need to prune a child and graft to another tree, that's fine, but in general it usually makes life a lot easier if you can walk up a tree as well as down it.Artist.set_figure has been part of the library for at least 18 years, and I'm not clear what the practical advantage of backing it out would be.

Latest commit reverts the changes in_constrained_layout andcontour.py where the new version did not explicitly pass in the renderer. Those were the only internal uses I think the old version was changing.

FWIW I have been wanting to make renderer optional for a long time too (because threading it through layers and layers of calls just so that texts can know their extents is a bit annoying). While I also agree with@tacaswell's point that cache invalidation is tricky, note that the question here is about the invalidation offigure._cachedRenderer; it doesn't really matter, IMO, whetherartist.get_window_extent() fetches the renderer fromartist.figure or whether we pass the renderer to it explicitly (because if we're doing this in a non-draw context, we most likely are layouting some parent artist (ultimately the toplevel figure) and are grabbing the renderer fromfigure._cachedRenderer anyways)? IOW, unless we carefully start avoiding refering to artist.figure, we're not really making the cache problem worse?

@tacaswell, can you reassess now that the internal uses have been cleared up. Note that this also cleans up our internal definition of the renderer to one location.