Fixed
Status Update
Comments
ch...@google.com <ch...@google.com> #2
Hi Ed, Thank you so much for these suggestions. I've been reviewing them and merging them in. Hopefully it should be live. I've included a thank you note too in the article.
ch...@google.com <ch...@google.com> #3
Great! Thanks a lot, I'll look for the live updates soon!
ch...@google.com <ch...@google.com> #4
Some of #3 is incorrect - the bounds can be expanded from the initial min/max values, so it is fine to have them start at the anchor points.
Meanwhile, I thought part of the problem might be calculating derivatives/etc for zero-length curves (of which there are many, given the way our shape rounding works). But adding in a check for this (setting the bounds of a curve to the same point when the anchors are equal within the distance epsilon) did not fix the problem; we still end up with bounds that are inside some of the curves (see attached screenshot)
Meanwhile, I thought part of the problem might be calculating derivatives/etc for zero-length curves (of which there are many, given the way our shape rounding works). But adding in a check for this (setting the bounds of a curve to the same point when the anchors are equal within the distance epsilon) did not fix the problem; we still end up with bounds that are inside some of the curves (see attached screenshot)
ap...@google.com <ap...@google.com> #5
Project: platform/frameworks/support
Branch: androidx-main
commit 958577b15712233aa487003deb0ab37de3af7ab7
Author: Chet Haase <chet@google.com>
Date: Wed Dec 20 13:21:53 2023
Added more bounds calculation utilities
Previously, calculateBounds() returned the estimated bounds
for a RoundedPolygon. This is reasonable in most cases, but sometimes
you want the actual/minimal bounds instead. Also, sometimes you want
the max bounds for an object that might be rotated within its container,
so you need to size the container appropriately.
This CL introduces options for bounds calculations to handle these
new cases, along with some minor cleanups along the way.
Bug: 317286450
Test: Existing tests pass, added new bounds tests
Relnote: Now more options for retrieving exact and max bounds
Change-Id: I6d49f468a28c1f360000e8370f02a50841f744e4
M graphics/graphics-shapes/api/current.txt
M graphics/graphics-shapes/api/restricted_current.txt
M graphics/graphics-shapes/src/androidInstrumentedTest/kotlin/androidx/graphics/shapes/PolygonTest.kt
M graphics/graphics-shapes/src/commonMain/kotlin/androidx/graphics/shapes/Cubic.kt
M graphics/graphics-shapes/src/commonMain/kotlin/androidx/graphics/shapes/RoundedPolygon.kt
M graphics/graphics-shapes/src/commonMain/kotlin/androidx/graphics/shapes/Utils.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/DebugDraw.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/MainActivity.kt
https://android-review.googlesource.com/2889768
Branch: androidx-main
commit 958577b15712233aa487003deb0ab37de3af7ab7
Author: Chet Haase <chet@google.com>
Date: Wed Dec 20 13:21:53 2023
Added more bounds calculation utilities
Previously, calculateBounds() returned the estimated bounds
for a RoundedPolygon. This is reasonable in most cases, but sometimes
you want the actual/minimal bounds instead. Also, sometimes you want
the max bounds for an object that might be rotated within its container,
so you need to size the container appropriately.
This CL introduces options for bounds calculations to handle these
new cases, along with some minor cleanups along the way.
Bug: 317286450
Test: Existing tests pass, added new bounds tests
Relnote: Now more options for retrieving exact and max bounds
Change-Id: I6d49f468a28c1f360000e8370f02a50841f744e4
M graphics/graphics-shapes/api/current.txt
M graphics/graphics-shapes/api/restricted_current.txt
M graphics/graphics-shapes/src/androidInstrumentedTest/kotlin/androidx/graphics/shapes/PolygonTest.kt
M graphics/graphics-shapes/src/commonMain/kotlin/androidx/graphics/shapes/Cubic.kt
M graphics/graphics-shapes/src/commonMain/kotlin/androidx/graphics/shapes/RoundedPolygon.kt
M graphics/graphics-shapes/src/commonMain/kotlin/androidx/graphics/shapes/Utils.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/DebugDraw.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/MainActivity.kt
ch...@google.com <ch...@google.com> #6
Problem fixed - we now offer the option to request actual bounds (or faster/approximated, based on a parameter to calculateBounds()).
We also offer a new API, calculateMaxBounds(), which returns the square bounds in which the object can be rotated without ever exceeding the bounds.
We also offer a new API, calculateMaxBounds(), which returns the square bounds in which the object can be rotated without ever exceeding the bounds.
Description
Meanwhile, the bounds are also limited to whatever the screen orientation of the shape is at the time. So if the caller was hoping to get the bounds once to calculate the size of the bounding view/composable and then rotate the shape within that area, they may find that the shape exceeds those bounds as it changes orientation. For a simple example, imagine a rectangle that is long in the x direction but short in the y direction, which would result in bounds that are similarly wide horizontally but short vertically, Rotating that rectangle would exceed the bounds in the Y direction quickly as the corners of the rectangle rotated outside of the original bounds.
It seems like we should provide more functionality for bounds calculations in two ways:
1) Exact bounds: Approximate bounds are sufficient for many purposes, and have the advantage of being cheap to compute (we are simply doing a bunch of float compares against all points in a shape). But if a caller wants the exact bounds for some reason, we should be able to calculate those by checking the bounds of the actual curves instead of just the points that created those curves. For example, in the attached screenshot of the clover, exact bounds would look closer to the yellow box than the green box, where the bounds met the outline of the clover's curves.
2) Max bounds: If a caller intends to rotate or otherwise change the orientation of a shape, we could calculate the max bounds. This is essentially the farthest point on any of the curves from the center, doubled, in both directions. For example, if the farthest point on a curve were (100, 100) away from the center, then the max bounds would be (-100, -100), (100, 100).
The caller can come up with these values already; they have access to the same underlying cubics that we would use to calculate these new bounds values. But it seems like the kind of utility that the library should provide directly to make it easier to position these shapes in a UI, where bounds help determine placement and sizing of the views/composables which contain these shapes.