add a ratchet option to dataLim update functions and associated autoscale functions

[ianhi]

Problem

I think this was best stated by @mwaskom in #17331 (comment)

What I really want from explicit limits / autoscaling is something closer to a ratchet: I want to set limits that won't hide to-be-added data that lie outside of the limits but will also not contract when to-be-added data lie inside the limits (minus the margin).

I am regularly running into this when making interactive plots. Trying to mix plot elements that may update with others that may not and some artists work with ax.relim while others do not. So it would be awesome if in addition to ratcheting behavior for set_{x,y}lim it was also implemented for the bbox dataLim updating methods.

Proposed Solution

add ratchet_x and ratchet_y options to:
ax.relim
ax.autoscale_view
and the bbox updating methods:

matplotlib/lib/matplotlib/transforms.py

Line 885 in ab45bcd

def update_from_data_xy(self, xy, ignore=None, updatex=True, updatey=True):

matplotlib/lib/matplotlib/transforms.py

Line 849 in ab45bcd

def update_from_path(self, path, ignore=None, updatex=True, updatey=True):

matplotlib/src/_path.h

Line 368 in c9bf76c

void update_path_extents(PathIterator &path, agg::trans_affine &trans, extent_limits &extents)

matplotlib/src/_path.h

Line 349 in c9bf76c

inline void update_limits(double x, double y, extent_limits &e)

I think the only place where the logic would actually need to be changed is in the update_limits function
and ratchet options to
ax.set_xlim
ax.set_ylim

Additional context and prior art

A user can get this behavior in python by themselves like this:

cur_ylims = ax.get_ylim()
ax.relim()
new_lims = [ax.dataLim.y0, ax.dataLim.y0+ax.dataLim.height]
ax.set_ylim(min(new_lims[0], cur_ylims[0]), max(new_lims[1], cur_ylims[1]))
ax.set_ylim(new_lims)

but this is likely less performant than if this was driven all the way down into the matplotlib c++ (I think?) and is not very convenient.

[jklymak]

I think you just want this at the high-level functions, not down into _path.h. update_path_extents etc have to return the actual extents, not ratcheted versions. These functions do not know anything about the global limits

[github-actions]

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!

[ianhi]

feature request is still wanted

[jklymak]

I'm not following the use case here. Can you give a set of calls that illustrate the workflow?

[mwaskom]

In the following snippet, the final x limits are tight around (2, 3), ignoring the limits I set previously:

f, ax = plt.subplots()
ax.set_xlim(0, 4, auto=True)
ax.plot([2, 3], [1, 2])

But if I set auto=False and a subsequent call places data outside of those limits, I can't see it:

f, ax = plt.subplots()
ax.set_xlim(0, 4, auto=False)
ax.plot([5, 6], [1, 2])

It would be helpful to have some way of saying "make the limits no less than (0, 4), but continue to auto-expand to additional data if necessary".

[jklymak]

I think I understood that. What I don't understand is why you would want to set the xlim before adding data?

[mwaskom]

Because a third party library might want to create a plot, set axis limits that work with that plot, and then return the axis to a user who may add additional artists.

(The specific usecase for seaborn is that its "categorical" functions set axis limits from -0.5 to +0.5 the min and max category indices, because matplotlib's multiplicative margin approach doesn't work great with categorical data. But that's just one example of the general usecase).

[jklymak]

Thanks. If the idea is to give third-party libraries flexibility, then that opens up the API to be a bit looser or cryptic than if we expected users to do this often.

I wonder if we did something like ax.set_xlim(0, 4, auto='lockmin') and inside set_xlim we passed auto down into the auto-lim machinery as a two-tuple auto=(0, 4). The auto-lim machinery isn't nice, so I'm not sure how easy this would be to get to work robustly. I prefer expanding one kwarg to adding clashing keywords.

[jklymak]

BTW, what happens if I explicitly call ax.set_xlim(20, 24)? Does it erase the previous window? Expand the window to include the new limits?

[mwaskom]

Calling set_xlim again changes the xlimits to the new values. The relevant parameter here only controls auto scaling (really auto limiting but that's the long-standing term).

[rcomer]

Does update_datalim do what you want?

import matplotlib.pyplot as plt

fig, ax = plt.subplots()
ax.update_datalim([(0, 0), (4, 0)], updatex=True, updatey=False)
ax.plot([2, 3], [1, 2])

ax.plot([2, 6], [1, 2])

[jklymak]

Wow, great find.... Obscure, but I think it is as described in the original request?