-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
FIX: Autoscale support in add_collection3d for Line3DCollection and Poly3DCollection #28403
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
greglucas
merged 5 commits into
matplotlib:main
from
scottshambaugh:3d_collection_autoscaling
Jun 24, 2024
Merged
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
195a208
Autoscale Line3DCollection and Poly3DCollection
scottshambaugh 0c7b7db
Update lib/mpl_toolkits/mplot3d/axes3d.py
scottshambaugh 691e849
Merge branch 'matplotlib:main' into 3d_collection_autoscaling
scottshambaugh e3e4640
Autoscale no longer needed
scottshambaugh a0ede40
Update lib/mpl_toolkits/mplot3d/axes3d.py
scottshambaugh File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Binary file modified
BIN
-4.99 KB
(91%)
lib/mpl_toolkits/mplot3d/tests/baseline_images/test_axes3d/voxels-named-colors.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While technically correct, I believe we should move the calculation of data lims down into the artists.
Current logic
This updates the
xy_dataLim
,zz_dataLim
BBoxes via.Bbox.update_from_data_xy/x/y()
, which in turn creates aPath
and calls.Bbox.update_from_path()
.This is quite a lot data pushing (and maybe copying) just to update dataLim bboxes.
Proposed logic
Separation of concerns: The Artists should have a function to get their data lims. These limits should be used to update the Bbox. Basically some
Bbox.update_from_box
, a kind of an in-placeBbox.union
, which we don't seem to have.This whole block should read something like
Note: "data lim" is intentionally vague as we currently don't have a good structure to describe it (we use two 2D Bboxes,
xy_dataLim
andzz_dataLim
.The minimal approach - if we don't want to redesign for proper 3d boxes, would be to let
get_data_lims()
return two BBoxes as well. In that case, I would keep this interface private_get_data_lims()
so that we can still change to a single 3D instance later.Edit: This is basically a generalization of
Collection.get_datalim
.matplotlib/lib/matplotlib/collections.py
Lines 239 to 306 in fa16860
Rough outline: We may start minimal with rolling a small
and implement
_get_datalim3d() -> _Bbox3d
on the 3d collections.Then
and
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this structure, but could we make that refactor its own issue?