Skip to content

Don't mark a patch transform as set if the parent transform is not set. #9426

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.

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

Merged
merged 2 commits into from
Jul 8, 2018

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Oct 16, 2017

When updating a patch from another artist, if the other artist's
transform is marked as "uninitialized" (_transformSet == False), then
don't mark the updatee's transform as set either.

Typically, this occurs if the updator has not been added to an Axes yet;
its transform will be set when that adding occurs. In that case, the
updatee's transform also needs to be set when actually being added to an
Axes.

Closes the incorrect transform part of #9377.

PR Summary

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@jklymak
Copy link
Member

jklymak commented Oct 16, 2017

Is there a good test for this?

Copy link
Member

@dstansby dstansby left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just putting a reminder here to include an image test related to #9435

@tacaswell tacaswell modified the milestones: v2.2, v2.1.1 Oct 19, 2017
@tacaswell
Copy link
Member

Sorry, changed my mind about where to target this to again.

@anntzer
Copy link
Contributor Author

anntzer commented Oct 21, 2017

To be honest, looking at it again, I am not even that certain that that the constructor of that Shadow class makes a lot of sense. Specifically, if I got it correctly, the ox and oy values are first multiplied by the dots-per-point conversion factor (e.g. 100/72 at 100dpi), then interpreted as offsets in data coordinates.

Which "of course(???...)" means that the shadow can move when you save the figure (as savefig.dpi does not have to equal figure.dpi)

@tacaswell
Copy link
Member

Looking at the history this goes back to JDH in 2004 so it pre-dates the transform machinery and I would guess added as a gee-whiz feature.

If you think it could be cleaned up for 2.2 👍

@anntzer
Copy link
Contributor Author

anntzer commented Oct 21, 2017

I'm not really convinced of the utility of providing this class, but heh.

A problem with interpreting ox, oy as offsets in data units is that the only two public APIs that rely on that class (other than Shadow itself) are pie(..., shadow=True) and legend(..., shadow=True), and for pie charts (which set the axes to polar) you'd better not interpret ox, oy in data coordinates.

So perhaps ox, oy should be interpreted either as axes coordinates or figure coordinates -- don't have a clear preference right now.

Edit: I think I'll let @dstansby figure out how to handle the same problem with arrows and just copy his approach :-)

@anntzer anntzer modified the milestones: needs sorting, v3.0 Feb 15, 2018
@anntzer anntzer force-pushed the shadow-transform branch 2 times, most recently from f99506f to 71ec6c3 Compare February 17, 2018 00:41
@anntzer
Copy link
Contributor Author

anntzer commented Feb 17, 2018

@dstansby test has been added (a while ago, but no worries)

@efiring
Copy link
Member

efiring commented Feb 25, 2018

@dstansby Would you like to re-review and merge if it is OK?

@anntzer anntzer mentioned this pull request Jun 10, 2018
6 tasks
anntzer added 2 commits June 24, 2018 00:51
When updating a patch from another artist, if the other artist's
transform is marked as "uninitialized" (`_transformSet == False`), then
don't mark the updatee's transform as set either.

Typically, this occurs if the updator has not been added to an Axes yet;
its transform will be set when that adding occurs.  In that case, the
updatee's transform also needs to be set when actually being added to an
Axes.
@anntzer anntzer force-pushed the shadow-transform branch from a9797a2 to f4d158d Compare June 23, 2018 23:04
@anntzer anntzer added the Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. label Jul 7, 2018
@anntzer
Copy link
Contributor Author

anntzer commented Jul 7, 2018

Seems ready to go in for 3.0 so labeling as RC.

@tacaswell tacaswell merged commit 3d19f94 into matplotlib:master Jul 8, 2018
@anntzer anntzer deleted the shadow-transform branch July 8, 2018 22:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants