This looks really cool, and I'm sure a number of folks would like this.

However, this would be a significant new maintenance burden, so there is a bit of a cost-benefit analysis to be done. Do we want a whole shadow canvas just for this feature? Are there other uses for this concept?

I'm also concerned about consistency. You increase the size of image pixels (OK), you increase the size of text (maybe OK), but you donot increase the thickness of lines. What happens to markers? Do they zoom or stay the same? It seems that if you want a zoom, then you want everything to zoom?

Thanks for the feedback, it's appreciated.

The maintenance concerns are totally understandable, and if it's determined this is too much to take on that is okay with me. I've tried to implement the_TransformRenderer andViewAxes so that they can be reused for other features where a view of another axes is needed (not just inset axes). The axes can be directly placed in the figure also, as shown below:

importmatplotlib.pyplotaspltfrommatplotlib.axes._zoom_axesimportViewAxesimportnumpyasnpnp.random.seed(1)fig=plt.figure()ax=fig.add_axes([0,0,0.5,1])ax.plot([iforiinrange(10)],"r-o")ax.text(3,2.5,"Hello World!",ha="center")ax.imshow(np.random.rand(30,30),origin="lower",cmap="Blues",alpha=0.5)defViewOf(ax):defviewgen(fig,*args,**kwargs):returnViewAxes(ax,*args,**kwargs)returnviewgenax2=fig.add_axes([0.5,0,0.5,1],axes_class=ViewOf(ax))ax2.set_aspect("equal")ax2.set_xlim(-15,45)ax2.set_ylim(-15,45)fig.show()

This auto-view feature is especially useful in interactive plots where you want the view to dynamically update when artists are added/removed, and is actually the primary reason I developed this feature.

Also, thanks for bringing up the visual inconsistencies when displaying zoomed in versions of lines, which were an oversight on my part. I've fixed it in the most recent push and everything should zoom in together now (as depicted in the figure below).

I've not looked into the details here: Could this start off as a third-party package. That's a good way to make code public if we are not yet sure whether we can maintain it in the main library.

I hadn't considered starting this off as a third-party package, though I think thats a great idea, I'll start working on getting one together as soon as I have some free time to do so. Is there any preference in how the third party package should integrate itself into matplotlib (API wise)?

I think the approach here looks quite cool, but I also agree that this can reasonably start as a third-party package.

We talked about this on the call today, this is super cool! The proposed path forward here is :

• make this a stand-alone package on@isaacrobinson2000 's account and get it on pypi
• once that is done, move it into the Matplotlib org (where we would obviously give@isaacrobinson2000 full control of the repo)
• in a year or two once we are sure the API has stabilized, then move the code into the main repo

I would suggest anytime you want to write anAxes method to instead write a free-function with the first argument being anAxes e.g.

ax.foo(...)foo(ax, ...)

The biggest advantage of letting this start as a stand-alone project is that you will be able to do releases more-or-less at will rather than being tied to our ~6mo intended (7-8mo actual) release cycle, push to the repo at will, and have the ability to aggressively make breaking changes to the API.

A concern about doing this as a stand-alone project is you are touching a number of private methods on the renderer, however those have been stable for a very long time and if the end-goal is to get this in the main repo, we think that is a reasonable risk.

I'm happy to hear that you're still interested in incorporating this into matplotlib. I think the concept of starting it as a third party package makes a lot of sense, as after making this PR I've realized there are some additional features that might be desired (such as adding elements to the axes which is a view of another, which currently doesn't work) and the API can be made much cleaner than the one in this PR. I've gone ahead and gone through with the first step above as suggested, and set up a repo and PyPI package for this project. I've also reworked the code so it can be easily applied to any Axes.

Github Repo:

https://github.com/isaacrobinson2000/matplotview

PyPI Package:

https://pypi.org/project/matplotview/

Since this is now a third party package, I'm assuming this PR is not really necessary nor helpful at this point, meaning it can probably be closed. Again, thanks for all of the helpful feedback!

Sounds good@isaacrobinson2000 !

Can you please add it tohttps://github.com/matplotlib/mpl-third-party as well (and make sure you add theFramework :: Matplotlib classifier)?

Thanks! I've made the above edits. Looking at the second step above, should I just go ahead and transfer the matplotview repo to the matplotlib organization, or is there something that should be done before I do that?

@isaacrobinson2000 Add me as a collaborator with I think admin rights on your repo and I'll do the move.

Thanks, let me know if you can do the move, there doesn't seem to be any options for collaborator permissions in the settings.

Hmm, they have changed their ACL from the last time I looked at doing this. Can you try transferring it to me?

Sure, consider it done!

This now lives athttps://github.com/matplotlib/matplotview