Skip to content

axes_grid in main library #17095

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jklymak opened this issue Apr 10, 2020 · 5 comments
Closed

axes_grid in main library #17095

jklymak opened this issue Apr 10, 2020 · 5 comments
Labels
API: consistency status: inactive Marked by the “Stale” Github Action topic: geometry manager LayoutEngine, Constrained layout, Tight layout topic: mpl_toolkit

Comments

@jklymak
Copy link
Member

jklymak commented Apr 10, 2020

As pointed out by @anntzer

OTOH it may be nice to slowly move axes_grid towards an API more consistent with the rest of mpl. From a very, very quick look, I guess its axis dict could be compared to normal axes' spines dict? (an AxisArtist is vaguely like a Spine, I guess).

Originally posted by @anntzer in #17069 (comment)

I think it would be better if we had a new axes_grid functionality in the main library, giving us freedom to change the API as we see fit.

The issue that axes_grid fixes is fundamentally:

import matplotlib.pylot as plt 

fig, axs = plt.subplots(2, 3 figsize=(5, 3))
for ax in axs.flat:
   ax.set_aspect(1)

returns the following:

AspectIssue

whereas axes_grid would pack these together vertically.

from mpl_toolkits.axes_grid1 import AxesGrid
fig = plt.figure(figsize=(3, 4), facecolor='0.7')
axs = AxesGrid(fig, 111,  # similar to subplot(111)
                 nrows_ncols=(2, 3),  
                 )
for ax in axs:
   ax.set_aspect(1)

AspectIssueAG

(Asside, yes, AxesGrid also makes some sharing assumptions, etc, that need not be made in general)

Neither constrained_layout nor tight_layout will do this packing for us.

proposals?

There are a few possible top-level APIs for this. The simplest may be:

axs = fig.add_axes_grid(gs)

where gs is a subplotspec, just like add_subplot.

@anntzer
Copy link
Contributor

anntzer commented Apr 23, 2020

I had a look at whether tight-packing could easily be achieved with tight_layout, but having spent a bit of time on it, I think the problem is underconstrained if you don't have assume some amount of sharing or at least that all axes have a fixed box_aspect (or fixed aspect + adjustable="datalim", which amounts to the same). Indeed, assume you have the following layout

1a Xa
1b Xb

where 1a and 1b are "square" axes and Xa and Xb have no aspect contraints, and assume additionally that the figure is initially too tall, so there's plenty of space between 1a and 1b:

   Xa
1a Xa
   Xa

   Xb
1b Xb
   Xb

Now do we add a lot of margins at the top and bottom to bringing 1a and 1b close to one another, at the cost of also squishing Xa and Xb which were just minding their own business and were able to use all the height available to them?
Obviously we "can" make a choice of behavior here, but then do we want to make that configurable, yada yada.

@jklymak
Copy link
Member Author

jklymak commented Apr 23, 2020

I'd argue that layout is squished as is. You squish vertically if the tallest element in each row still have vertical space

1a    
1a     Xa
1a

       Xb
1b     Xb
       Xb

Would also be as good as you can get.

I am working on all this logic for _constrained_layout but I'm not convinced its any different for tight_layout

For what I've done so far, the real issues come in when there are colorbars....

@jklymak
Copy link
Member Author

jklymak commented Apr 23, 2020

@anntzer its a complete mess right now, but this is what I did for CL so far: #17232

@github-actions
Copy link

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Jul 21, 2023
@jklymak
Copy link
Member Author

jklymak commented Jul 21, 2023

This is basically layout='compressed' so I think we can close this.

@jklymak jklymak closed this as completed Jul 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API: consistency status: inactive Marked by the “Stale” Github Action topic: geometry manager LayoutEngine, Constrained layout, Tight layout topic: mpl_toolkit
Projects
None yet
Development

No branches or pull requests

2 participants