[Bug]: `set_position` does not work on an inset_axes

[kdschlosser]

Bug summary

Setting the position is an inset axes using the set_position method that is available for the inset axes doesn't change the position of the inset axes.

Code for reproduction

import numpy as np

from matplotlib import cbook
from matplotlib import pyplot as plt
import threading

fig, ax = plt.subplots()

# make data
Z = cbook.get_sample_data("axes_grid/bivariate_normal.npy")  # 15x15 array
Z2 = np.zeros((150, 150))
ny, nx = Z.shape
Z2[30:30+ny, 30:30+nx] = Z
extent = (-3, 4, -4, 3)

ax.imshow(Z2, extent=extent, origin="lower")

# inset Axes....
x1, x2, y1, y2 = -1.5, -0.9, -2.5, -1.9  # subregion of the original image
axins = ax.inset_axes(
    [0.75, 0.25, 0.25, 0.25],
    xlim=(x1, x2), ylim=(y1, y2), xticklabels=[], yticklabels=[])
axins.imshow(Z2, extent=extent, origin="lower")

ax.indicate_inset_zoom(axins, edgecolor="black")


event = threading.Event()
import time

def do():
    time.sleep(3)
    print('setting position')
    axins.set_position([0.45, 0.65, 0.50, 0.50])
    fig.canvas.draw_idle()


t = threading.Thread(target=do)
t.daemon = True
t.start()
plt.show()

Actual outcome

The inset axes doesn't move at all

Expected outcome

The inset axes should move when new position data is given to it.

Additional information

Maybe there is something that I am missing? I am doing an idle draw of the figure after I set the position, didn't make any difference.

Operating system

Windows 11

Matplotlib Version

3.10.7

Matplotlib Backend

tkagg & wxagg

Python version

3.11

Jupyter version

No response

Installation

pip

[jklymak]

Can you test this without threading?

[jklymak]

OK, this indeed does not work.

inset_axes is not placed using the same mechanism as a normal axes, and it is only placed once and we do not have a public API to move it after its placed. However, it is implemented as just a plain axes with its own axes_locator.

Probably to fix this properly, we'd want to wrap inset_axes in a new class that does the right thing on set_position or on a similar call. I don't think there are any fundamental difficulties to doing this, but it's not currently available. In the meantime you can remove and re-add the inset. I don't think it'll be any cheaper even if we do end up adding extra methods.

Alternately, you could redefine the axes_locator, but the class we use to do the transform is private, probably to minimize API cross-section.

from matplotlib.axes._base import _TransformedBoundsLocator
bounds = [0.45, 0.65, 0.50, 0.50]
transform = ax.transAxes
inset_locator = _TransformedBoundsLocator(bounds, transform)
axins.set_axes_locator(inset_locator)

[timhoffm]

Probably to fix this properly, we'd want to wrap inset_axes in a new class that does the right thing on set_position or on a similar call.

This is slightly complicated because the Axes subclass is not fixed, but is dynamically determined at runtime from the projection. We don't want to define a subclass for every projection ( and cannot for user-defined ones). Alternatives are dynamically creating the subclass in the inset_axes call, which has disadvantages in documentation and type annotations; or using multiple inheritance to override set_position, but that's delicate to get right. - Also just realizing now, that would still leave us with the dynamic creation issue.

Alternatively, but unexplored, could we modify the base implementation of set_position so that it can to the right thing on an Axes with a _TransformedBoundsLocator?

[timhoffm]

Minimal solution would be to document that set_position is not supported on inset axes.

[timhoffm]

I'm also unclear whether set_position should work this way. It could be regarded as semantic change of the API if we here interpret the position relative to the patent axes. But also maybe not. In regular cases position is always absolute. One could argue that the absolute position is automatically determined and you cannot set it, in which case the correct solution would be a new method set_inset_position() with the same subclassing issues. One could alternatively argue that position is relative to the containing element (figure/parent axes) but we have no clear concept for that.

[kdschlosser]

The reason for me moving it is because of window resizing and the inlay not staying locked a position. It wander as I resize the window. This is not idea to have happen.

My use case is I am using it for a 3d plot as a way to identify what portion of the plot is being looked at. Much like the zoom example except I am doing it with a 3d plot instead. The wandering of the inlay as the window gets resized it the issue. It wanders right into the middle of the plot when it is originally set at the bottom corner. It goes back to where it should once I put the window back to the size it was originally at.

It would be fantastic if there was a way to either have a second figure that I can put into it's own window or even better would be to have a completely separate draw even take place so the 2 are able to be rendered independent of each other.

Also I did try removing and adding it again. It doesn't work. I am able to remove it but not add it back. If I was able to do that it would be OK with doing that but it's not possible. which stinks as well because I wanted to offer different views in the inlay that could be changed dynamically.

There are some real use cases for it. The ability to drill down into groups of data.. Say you have a bar graph and that bar graph show things like payroll, accounts payable, etc... being able to click on the payroll and have an inlay open up that provides a graph with payroll broken down into health care, taxes, etc... Click on a blank area and the inlay closes or clock on another bar to have it expand out that group. You would want to have the ability to position the inlay in an area that is not blocking anything or you want to have it close to the group that was being expanded. If it was able to have it's position set then making it so the inlay is able to be moved around the plot is really easy to do...

Here is what I am talking about with the inlay moving into the middle of the plot...

and here is an example of what would be a user click and move if the inlay was able to have it's position changed.

[kdschlosser]

Another use case would be to show something like this for 3d plots...

That could be shown in an inlay that is also a 3d plot and you pass the camera view and the rotation, azimuth and elevation to the inlay plot so the axis indicator will show the orientation of what is being seen in the plot.

I am actually in the middle of writing the code to plot that kind of an axis indicator into an inlay. That was what I was working on before I responded here...

[kdschlosser]

Oh I also did want to throw out there is you notice in those GIF videos there is no flickering when things are being moved around. I am using the wxagg backend and I patched it to fix the flickering.

Another thing I did was I wrote code that uses the wxPython native event system for handling the events from matplotlib. They both work at the same time so there is no broken API. The user is able to choose which one they want to use. I found it easier to use the wx events because I am familiar with them. All key, mouse and window events are handled properly and the user is able to collect an artist from the event if an artist has been clicked on. key data is also passed along in mouse events so if a user wants to react on holding down a key while clicking the mouse they are able to collect both he mouse data and the key data form the mouse event. Only the coordinates of the mouse get passed along with a key event no button clicks or anything like that. I could add a very limited set of the mouse data into a key event and it would be added as key modifiers for the button presses.

If there is interest in that as well lemme know and I can do a PR for it.

[rcomer]

Previous discussion in the area: #12985

[kdschlosser]

OK so set_position really doesn't matter for an inlay. As it actually turns out having that function to add an inlay really should not exist. Having it should simply be a convenience function if anything for adding and positioning an axes to the figure and nothing more.

no monkey patching involved to make this work. I did have to subclass the backend I am using to collect mouse events for the positioning and to override the draw function to add the red box when moving the "inlay" which is really not an inlay so to speak. All I did was add an additional 3d axes by constructing the axes and then adding it to the figure using the add_axes method. a simple call to shareview for the main axes passing the inlay axes to it and calling inlay.grid(False), inlay.patch.set_visible(False) and inlay.set_axis_off() to eliminate the grid, ticks and axis labels as well as make the background transparent. Everything used is in the public facing API.

I know that people have asked about doing this exact thing only to be told it is not able to be done. It CAN be done and it is able to be done pretty easily as well. It would be very easy to modify the inlay functions for the axes class so it will simply add a new axes class of the users choosing to the figure.

[jklymak]

Yes for sure if the axes is fixed in figure space then just adding the axes is preferred to an inset.

[kdschlosser]

I didn't know that they would render one on top of the other like that and that I would also be able to remove the background and axis markers.