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

Skip to content

Define FloatingAxes boundary patch in data coordinates. #20254

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 1 commit into from
Jul 20, 2021

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented May 18, 2021

Currently, the boundary patch of FloatingAxes is drawn in "parent axes
data" (rectilinear) coordinates, using manual interpolation as defined
in get_boundary.

Instead, it can be defined in child axes data coordinates, and use
helper_trf + transData as transform, relying on interpolation
mechanisms already present in the transform machinery (for example, this
means that polar FloatingAxes benefit from the more-accurate
transforming of circular arcs).

Likewise, adjust_axes_lim can use normal path methods to get its
extents, rather than relying on manual interpolation. This is the cause
of the baseline image tolerance change: in test_curvelinear3, for
example, we now have exactly bbox.xmin = bbox.ymin = -10 and
bbox.xmax = bbox.ymax = +10 rather than slightly different values
arising from interpolation and inaccurate transform composition. (But
one can manually check that the changes are all just tiny shifts.)

(On the other hand, I'll likely further change these baselines in the
future, so let's not update the files right now.)

PR Summary

PR Checklist

  • Has pytest style unit tests (and pytest passes).
  • Is Flake 8 compliant (run flake8 on changed files to check).
  • New features are documented, with examples if plot related.
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).
  • Conforms to Matplotlib style conventions (install flake8-docstrings and run flake8 --docstring-convention=all).
  • New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
  • API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).

@anntzer anntzer added this to the v3.5.0 milestone May 18, 2021
@anntzer anntzer force-pushed the fast branch 3 times, most recently from e11139d to 4e95320 Compare May 18, 2021 12:03
@jklymak jklymak marked this pull request as draft June 24, 2021 15:10
@anntzer anntzer marked this pull request as ready for review July 8, 2021 06:47
@anntzer anntzer force-pushed the fast branch 2 times, most recently from 1c5ef39 to 11d91c6 Compare July 8, 2021 06:51
Currently, the boundary patch of FloatingAxes is drawn in "parent axes
data" (rectilinear) coordinates, using manual interpolation as defined
in get_boundary.

Instead, it can be defined in child axes data coordinates, and use
`helper_trf + transData` as transform, relying on interpolation
mechanisms already present in the transform machinery (for example, this
means that polar FloatingAxes benefit from the more-accurate
transforming of circular arcs).

Likewise, adjust_axes_lim can use normal path methods to get its
extents, rather than relying on manual interpolation.  This is the cause
of the baseline image tolerance change: in test_curvelinear3, for
example, we now have exactly `bbox.xmin = bbox.ymin = -10` and
`bbox.xmax = bbox.ymax = +10` rather than slightly different values
arising from interpolation and inaccurate transform composition.  (But
one can manually check that the changes are all just tiny shifts.)

(On the other hand, I'll likely further change these baselines in the
future, so let's not update the files right now.)
Comment on lines +327 to +329
(x0, _), (x1, _), (y0, _), (y1, _) = map(
self.get_grid_helper().get_data_boundary,
["left", "right", "bottom", "top"])
Copy link
Member

Choose a reason for hiding this comment

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

Do we want to introduce get_data_boundary() without parameters as returning all four; in analogy to get_boundary()?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think I would rather fix FloatingAxes so to make get_xlim()/get_ylim() and even set_xlim()/set_ylim() work, rather than introducing additional ad-hoc APIs.

@jklymak jklymak merged commit c9f0c25 into matplotlib:master Jul 20, 2021
@anntzer anntzer deleted the fast branch July 20, 2021 16:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants