-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Open
Labels
Description
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.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
. - Syncing dataLim for shared axes is tedious
- The concept does not work well with clearing shared axes ([MNT]: Define Axes.clear semantics #28851 (comment)).
Proposed fix
We should rearchitect data limit handling:
Break the strong coupling between Axes and data limits: Create a _DataLimits
class that does all the limit related operations:
class _DataLimits:
def __init__(axes):
self.axes = axes
self.datalim = BBox.null()
def relim(...):
# pull pull code from Axes.relim in here
and remove it from Axes
class AxesBase:
def __init__(...):
[...]
self._datalimits = _DataLimits(self)
# remove self.dataLim
@property
def dataLim(self):
return self._datalimits.dataLim
@dataLim.setter
def dataLim(self, lim):
self._datalimits.dataLim = lim
def relim(...):
self._datalimits.relim(....)
When we have managed this, we can improve:
- 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.