Add private Artist-level autoscale participation flag by Archiljain · Pull Request #31166 · matplotlib/matplotlib

Archiljain · 2026-02-16T13:40:45Z

Introduce a private Artist-level _in_autoscale flag (mirroring _in_layout) and gate autoscaling centrally in Axes.relim().

This PR is preparatory infrastructure only and does not intend to change existing behavior. Follow-up work will build on this to address collection.

…ssion test

dstansby · 2026-02-17T15:08:28Z

Thanks for opening this PR! Could you give a bit more context to what future work this change will enable?

timhoffm · 2026-02-17T16:09:21Z

See #31128 (comment)

timhoffm

This is not yet appropriate

the getter and setter must be private.
the in autoscale logic is not implemented
the artists need to be pre-defined with in autoscale in alignment with their current behavior

To be clear, this PR must provide the full in autoscale logic, shifting the in-behavior hard-coded logic to only depending on the artist property.

…elim regression test (to be added in follow-up PR)

Archiljain · 2026-02-18T20:34:27Z

The scatter relim regression test was removed from this PR since it exercises follow-up behavior (PR2). I’ll reintroduce it once PathCollection autoscaling is wired via the new artist flag.

Archiljain · 2026-02-18T20:35:02Z

Thanks for the clarification — I’ve updated the PR so autoscale participation is fully artist-driven. The flag is now initialized in the add_* methods to preserve existing behavior, and relim() only gates on the artist property.

Archiljain · 2026-02-18T20:40:25Z

@dstansby Thanks for the question!

The goal of this change is to make inclusion in autoscaling an explicit, artist-level property, rather than relying on hard-coded type checks spread across Axes methods.

In the short term, this PR does not change behavior; it only introduces the minimal infrastructure needed to express whether an artist participates in autoscaling in a uniform way.

This enables follow-up work to:

-Make add_collection(..., autolim=...) and similar APIs consistent across artist types.

-Decouple autoscaling decisions from specific artist classes, allowing more predictable and testable behavior.

-Incrementally refactor limit handling to query artists for their autoscale participation, instead of embedding logic in Axes.relim and related methods.

-Concretely, this is intended to support the follow-up PRs discussed above, where conditional autoscaling of collections and a more unified limits architecture can be implemented without further ad-hoc checks.

timhoffm · 2026-02-21T05:03:54Z

lib/matplotlib/axes/_base.py

        if a.get_clip_path() is None:
            a.set_clip_path(self.patch)
        self.stale = True
+        a._set_in_autoscale(False)


is this needed?

Yes — the intent was to make the current behavior explicit.

add_artist historically does not opt the artist into autoscaling, so setting _in_autoscale(False) there makes that behavior explicit and avoids relying on defaults. This keeps relim() fully driven by the artist property rather than by implicit assumptions.

I'd argue otherwise: For all standard cases this does nothing, because the default value is False. It would only have an effect a user would manually do artist.set_in_autoscale(True); ax.add_artist(artist). But we just have created set_in_autoscale() so that we don't have do consider backward compatibility in that case. And logically, overriding the in_autoscale settting through add_artist() would be surprising. So it's better to leave this out here and rely on the global default that an artist does not take part in autoscaling, unless we've explicitly opted in for that.

timhoffm · 2026-02-21T05:04:49Z

lib/matplotlib/artist.py

+        ----------
+        b : bool
+        """
+        self._in_autoscale = b


To be checked: Do we need to set the self._stale flag?

I don’t think _set_in_autoscale should mark the artist as stale.

The flag only affects whether the artist participates in future autoscaling; it doesn’t change the artist’s visual state or require a redraw on its own. In practice it’s set during add_*, before any drawing occurs, so marking it stale would be unnecessary.

Ok, so the argument is that changing in_autoscale will not result in automatic recalculation of the limits. Accepted.

Can you please add a sentence on this to the docstring.

lib/matplotlib/artist.py

timhoffm · 2026-02-26T12:33:14Z

lib/matplotlib/axes/_base.py

                self._request_autoscale_view()

        self.stale = True
+        collection._set_in_autoscale(autolim)


For the scope of the PR, this does not have any effect as collections do not take part in limit calculation. So we could leave this out.

Note that currently the autolim parameter is a one-time action to update the data limits.

You may keep it in anticipation of the upcoming changes for #31128. But if you do, you should move it to before if autolim: and add a comment that this does not have any effect yet.

Thanks for the clarification — that makes sense.
I’ll remove this for now and keep the PR focused on introducing the artist-level flag without anticipating collection behavior. We can wire this up properly once collections participate in limit calculation.

timhoffm · 2026-02-26T12:34:46Z

lib/matplotlib/axes/_base.py

+    def _update_collection_limits(self, collection):
+     offsets = collection.get_offsets()
+     if offsets is not None and len(offsets):
+        self.update_datalim(offsets)
+
+


Please remove. This is not within the scope of this PR but belongs in #31128.

Sure — removed. I’ll keep collection limit handling for #31128 and keep this PR focused on introducing the artist-level autoscale flag only.

Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>

Archiljain · 2026-02-26T15:59:02Z

Thanks for the review and guidance!
I’ll wait for this to be merged and then follow up with the next PR2 as discussed in #31128 .

QuLogic · 2026-03-07T06:11:57Z

I suppose this should have been squash-merged, or at least rebased without extraneous changes, as #31128 has now been marked as merged even though all of those changes were reverted in follow-up commits in this PR, so #31128 is effectively not merged.

timhoffm · 2026-03-07T07:59:48Z

Yes, this should have been squashed-merged. :/

Archiljain · 2026-03-07T09:44:43Z

Thanks for the review and guidance throughout this PR.
I’ll follow up with the next step discussed in #31128 building on this change.

Archiljain added 4 commits February 10, 2026 14:07

Fix relim() to update limits for scatter PathCollection and add regre…

529d37c

…ssion test

Refactor: use _update_collection_limits for scatter handling in relim

defd13e

Fix ruff E302: add missing blank line before test

fbb623e

Add private Artist-level autoscale participation flag

5bf5273

github-actions bot added the topic: axes label Feb 16, 2026

timhoffm reviewed Feb 17, 2026

View reviewed changes

QuLogic added the status: needs revision label Feb 17, 2026

Archiljain added 2 commits February 19, 2026 00:27

Make autoscale participation fully artist-driven and Remove scatter r…

7247fa5

…elim regression test (to be added in follow-up PR)

fixing CI fails

b527465

timhoffm reviewed Feb 21, 2026

View reviewed changes

timhoffm reviewed Feb 26, 2026

View reviewed changes

Archiljain and others added 4 commits February 26, 2026 18:14

removed the set_in_autoscale from add_artist

0ad2c0a

Update lib/matplotlib/artist.py

6c702b6

Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>

Update lib/matplotlib/artist.py

bcf2fc2

Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>

Removed update limit function and autolim

31f59f4

timhoffm approved these changes Feb 26, 2026

View reviewed changes

timhoffm removed the status: needs revision label Feb 26, 2026

ksunden approved these changes Mar 6, 2026

View reviewed changes

ksunden added this to the v3.11.0 milestone Mar 6, 2026

ksunden merged commit 59ca203 into matplotlib:main Mar 6, 2026
41 checks passed

QuLogic mentioned this pull request Mar 7, 2026

Fix relim() ignoring scatter PathCollection offsets #31128

Merged

Uh oh!

Conversation

Archiljain commented Feb 16, 2026

Uh oh!

dstansby commented Feb 17, 2026

Uh oh!

timhoffm commented Feb 17, 2026

Uh oh!

timhoffm left a comment

Choose a reason for hiding this comment

Uh oh!

Archiljain commented Feb 18, 2026

Uh oh!

Archiljain commented Feb 18, 2026

Uh oh!

Archiljain commented Feb 18, 2026

Uh oh!

timhoffm Feb 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

timhoffm Feb 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Archiljain commented Feb 26, 2026

Uh oh!

Uh oh!

QuLogic commented Mar 7, 2026

Uh oh!

timhoffm commented Mar 7, 2026

Uh oh!

Archiljain commented Mar 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

timhoffm Feb 21, 2026 •

edited

Loading

timhoffm Feb 21, 2026 •

edited

Loading