You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For now, this is a ticket to collect my thoughts. It's not completely thought though and therefore not yet actionable.
Data limits are stored in Axes.dataLim and updated via a push-mechanism (plotting functions that add artists also update the data limits). This has several disadvantages:
Changes to the data within an Artist cannot be automatically be picked up; one needs to explicitly call Axes.relim.
DataLimits could handle multiple Axes. This allows much better handling of sharing We can then have one DataLimits instance, which collects data information from multiple Axes. This single DataLimits instance is used on all shared Axes. (Note: We likely have to have separate DataLimits objects for x and y to support all kinds of sharing)
We can make DataLimits lazy - they are just called from the Axes now. All the state handling is encapsulated in DataLimits. (Possibly, combined with a refactoring so that we can query Artists for their data limits. - Then _DataLimits just has to loop over all artists on all handled Axes and collect the limit information.
Edit: Thinking about it a bit more: data limits should not be shared - they are an individual property of the respective Axes. What needs synchronization / sharing on sharex/y is view limits.
Since Axes.dataLim is public, people can write to it (either replace the whole instance or update its attributes). Properly shielding against that is quite a hassle, because we'd need to have an immuatble BBox. So for the time being, we are bound to dataLim as BBox being the data representation. That combined with the realization that data limits should not be shared implies there's likely not a large benefit in refactoring.
Sharing should be handled on the level view limits.
Summary
For now, this is a ticket to collect my thoughts. It's not completely thought though and therefore not yet actionable.
Data limits are stored in
Axes.dataLimand updated via a push-mechanism (plotting functions that add artists also update the data limits). This has several disadvantages:Axes.relim.Proposed fix
We should rearchitect data limit handling:
Break the strong coupling between Axes and data limits: Create a
_DataLimitsclass that does all the limit related operations:and remove it from Axes
When we have managed this, we can improve:
_DataLimitsjust has to loop over all artists on all handled Axes and collect the limit information.Edit: Thinking about it a bit more: data limits should not be shared - they are an individual property of the respective Axes. What needs synchronization / sharing on
sharex/yis view limits.Since
Axes.dataLimis public, people can write to it (either replace the whole instance or update its attributes). Properly shielding against that is quite a hassle, because we'd need to have an immuatble BBox. So for the time being, we are bound todataLimas BBox being the data representation. That combined with the realization that data limits should not be shared implies there's likely not a large benefit in refactoring.Sharing should be handled on the level view limits.
We can still make the data limits lazy - as we do with
viewLimhttps://github.com/matplotlib/matplotlib/blob/b2e8b936e057ffc7b0d1505c5703988172041d4b/lib/matplotlib/axes/_base.py#L889-893.