Repository navigation
[MNT]: new public method to help title positioning #29385
Description
Activity
First step: The optimization from #28300 was only valid for the case of rectilinear Axes. We can add that optimization right now if we limit it to Ax.name == “rectilinear” and keep the old behavior for all other cases. This is the 80/20 solution (good gain with little effort). And I believe we should do this.
Possible further steps:
We generally have a backward compatibility problem with the optimization wrt subclasses. We don’t know whether they are ok with the optimization. To not break them, the optimization has to be opt-in, which also means we have to keep the unoptimized code around (at least for a time). I’m a bit hesitant to force subclasses to copy that code and provide their own implementation. Maybe we should keep it and classes can set a flag to use the optimized version? So far/with that we wouldn’t need a dedicated function.
The function comes into play where considering ticks and axis label are not enough - like in cartopy. It can indeed help 3rd party Axes subclasses. But IMHO we can decouple the topics. The function does not help with the (non-)optimization topic as it is not backwards compatible/ convenient for subclasses that don’t introduce extra artists.
Reacted by Ruth ComerA simpler solution for the Cartopy case might be to add a public attribute to Axes, which is a list1 of "extra artists" that should be considered for the title. Then Axes._update_title_position just needs to loop through and call get_tightbbox on each to update top. It's slightly complicated in Cartopy's case because the relevant text objects are children of a container artist: they do not exist until the first call to draw or get_tightbbox on the parent and might move on the next call. I note that _update_title_position is called before the artists are drawn. Perhaps we could just use the tight bbox of the parent though - we did make that calculation more efficient not long ago. 🤔
Footnotes
-
or other iterable ↩
-
I'm going to close this one. The polar issue is fixed. As for Cartopy, this is by no means the only private API it is reaching into - I only brought it up here because of the parallel with the polar issue.
Summary
Proposed fix
Factor out a public method that returns top. Making it public means it can safely be overridden in subclasses such as PolarAxes and Cartopy's GeoAxes. Knowing it can/should be overridden in subclasses means that in the parent Axes we can use the most efficient approach that works for Axes.