Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Bug]: axvspan no longer participating in limit calculations #28383

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
bmcfee opened this issue Jun 12, 2024 · 3 comments · Fixed by #28486
Closed

[Bug]: axvspan no longer participating in limit calculations #28383

bmcfee opened this issue Jun 12, 2024 · 3 comments · Fixed by #28486
Milestone
v3.9.1

Comments

@bmcfee
Copy link
Contributor

bmcfee commented Jun 12, 2024

Bug summary

Since upgrading to matplotlib 3.9, axvspan plots no longer seem to be included in limit calculations. I suspect this is due to the change from Polygon to Rectangle, but it does seem to have some unintended consequences.

Code for reproduction

In [2]: fig, ax = plt.subplots()

In [3]: ax.axvspan(0.5, 1.0)
Out[3]: <matplotlib.patches.Rectangle object at 0x7080118bbf80>

In [4]: ax.set(title='Matplotlib 3.9.0')
Out[4]: [Text(0.5, 1.0, 'Matplotlib 3.9.0')]

Actual outcome

image

Note that the axis limits are still centered at 0, and the vspan is out of frame.

Expected outcome

image

In 3.8.4, the limits would adapt to the location of the generated artist.

Additional information

This is causing us some problems in mir_eval, where we have high-level plot constructors that are built entirely from axvspans for showing time-series segmentation labels.

Operating system

all

Matplotlib Version

3.9.0

Matplotlib Backend

tkagg, but shouldn't matter

Python version

3.12

Jupyter version

n/a

Installation

pip
@bmcfee bmcfee mentioned this issue Jun 12, 2024
Closed
@ksunden
Copy link
Member

ksunden commented Jun 12, 2024

This may be duplicate of #28341, which has a patch, but has not been put into a PR yet, I believe.

That said, the discussion there was about axhspan and indicated that axvspan was unaffected, so may not be exactly the same...

@bmcfee
Copy link
Contributor Author

bmcfee commented Jun 13, 2024

That said, the discussion there was about axhspan and indicated that axvspan was unaffected, so may not be exactly the same...

I took a look at the proposed patch in #28341, and I don't think it addresses the issue.

In axhspan, the proposed fix was to .copy() the horizontal interval when updating the datalim:

matplotlib/lib/matplotlib/axes/_axes.py

Lines 1028 to 1031 in 54729db

# For Rectangles and non-separable transforms, add_patch can be buggy
# and update the x limits even though it shouldn't do so for an
# yaxis_transformed patch, so undo that update.
ix = self.dataLim.intervalx

and the post in thread indicates that this is unnecessary for vspan, which already has the .copy():

matplotlib/lib/matplotlib/axes/_axes.py

Lines 1091 to 1094 in 54729db

# For Rectangles and non-separable transforms, add_patch can be buggy
# and update the y limits even though it shouldn't do so for an
# xaxis_transformed patch, so undo that update.
iy = self.dataLim.intervaly.copy()

However, that's only applied to the y-axis, and it's the x-axis that is causing the issue here.

So I think these are two related, but distinct problems.

@tacaswell tacaswell added this to the v3.9.1 milestone Jun 14, 2024
@QuLogic
Copy link
Member

QuLogic commented Jun 27, 2024 •
edited
Loading

So the problem here is that for patches, we ask for whether it contains the data transform:

matplotlib/lib/matplotlib/axes/_base.py

Lines 2445 to 2448 in d347c32

patch_trf = patch.get_transform()
updatex, updatey = patch_trf.contains_branch_seperately(self.transData)
if not (updatex or updatey):
return

and for Rectangle this returns False for both x&y. This is likely because a Rectangle is a unit rectangle, with a scaling transform + the data transform.

Since Patch.get_transform() == patch transform + data transform, it's possible that we may want to check data transform, and then use patch transform directly for the datalim update. Something like:

diff --git a/lib/matplotlib/axes/_base.py b/lib/matplotlib/axes/_base.py
index 1cf56c90cc..5f37710ee6 100644
--- a/lib/matplotlib/axes/_base.py
+++ b/lib/matplotlib/axes/_base.py
@@ -2415,17 +2415,17 @@ class _AxesBase(martist.Artist):
         if len(vertices):
             vertices = np.vstack(vertices)
 
-        patch_trf = patch.get_transform()
-        updatex, updatey = patch_trf.contains_branch_seperately(self.transData)
+        data_trf = patch.get_data_transform()
+        updatex, updatey = data_trf.contains_branch_seperately(self.transData)
         if not (updatex or updatey):
             return
         if self.name != "rectilinear":
             # As in _update_line_limits, but for axvspan.
-            if updatex and patch_trf == self.get_yaxis_transform():
+            if updatex and data_trf == self.get_yaxis_transform():
                 updatex = False
-            if updatey and patch_trf == self.get_xaxis_transform():
+            if updatey and data_trf == self.get_xaxis_transform():
                 updatey = False
-        trf_to_data = patch_trf - self.transData
+        trf_to_data = patch.get_patch_transform()
         xys = trf_to_data.transform(vertices)
         self.update_datalim(xys, updatex=updatex, updatey=updatey)

@QuLogic QuLogic mentioned this issue Jun 28, 2024
Merged
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
v3.9.1
Development

Successfully merging a pull request may close this issue.

Fix CompositeGenericTransform.contains_branch_seperately QuLogic/matplotlib
4 participants
@tacaswell @QuLogic @bmcfee @ksunden