Fixed
Status Update
Comments
ma...@google.com <ma...@google.com>
sg...@google.com <sg...@google.com>
sg...@google.com <sg...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-main
commit a330c0d3bcdd41326f37968a60e6084ad4a2e32c
Author: Chet Haase <chet@google.com>
Date: Wed Jul 05 07:26:46 2023
Convert APIs using PointF to use Float instead
PointF is a convenient mechanism for passing around x.y values
representing 2D points. But there are downsides, including:
- Converting to PointF: You may not have the data in PointF form
to begin with, so using an API which takes PointF requires converting
the data to that form (including allocating a PointF object every time)
- Mutability: Point structures can be mutated internally, causing
unpredictability in what that mutation means. Should the library
react to those changes? Ignore them? Do defensive copies (requiring
even more allocations)? Using primitive types like Float make the
behavior more obvious (by making the data inherently immutable).
- Allocations: Whenever we use object types, there are necessarily
allocations on the Java heap for them. This puts pressure on the GC
at both allocation and collection time. Given the amount of points
being passed around (especially at morph creation time, when curves
are being split and created), this causes a lot of PointF objects to
be allocated (even temporarily). Using Float avoids that problem.
Also fixed bug with unclosed paths causing discontinuity at the
start/end point.
Bug: 276466399
Bug: 290254314
Test: integration and unit tests pass
Relnote: PointF parameters changed to Float pairs
Change-Id: Id4705d27c7be31b26ade8186b99fffe2e2f8450e
M graphics/graphics-shapes/api/current.txt
M graphics/graphics-shapes/api/restricted_current.txt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicShapeTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonMeasureTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/RoundedPolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/ShapesTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/TestUtils.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Cubic.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/CubicShape.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FeatureMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FloatMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Morph.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/PolygonMeasure.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/RoundedPolygon.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Shapes.kt
M graphics/graphics-shapes/src/main/java/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/ShapeEditor.kt
M graphics/integration-tests/testapp/src/main/java/androidx/graphics/shapes/test/MaterialShapes.kt
https://android-review.googlesource.com/2649119
Branch: androidx-main
commit a330c0d3bcdd41326f37968a60e6084ad4a2e32c
Author: Chet Haase <chet@google.com>
Date: Wed Jul 05 07:26:46 2023
Convert APIs using PointF to use Float instead
PointF is a convenient mechanism for passing around x.y values
representing 2D points. But there are downsides, including:
- Converting to PointF: You may not have the data in PointF form
to begin with, so using an API which takes PointF requires converting
the data to that form (including allocating a PointF object every time)
- Mutability: Point structures can be mutated internally, causing
unpredictability in what that mutation means. Should the library
react to those changes? Ignore them? Do defensive copies (requiring
even more allocations)? Using primitive types like Float make the
behavior more obvious (by making the data inherently immutable).
- Allocations: Whenever we use object types, there are necessarily
allocations on the Java heap for them. This puts pressure on the GC
at both allocation and collection time. Given the amount of points
being passed around (especially at morph creation time, when curves
are being split and created), this causes a lot of PointF objects to
be allocated (even temporarily). Using Float avoids that problem.
Also fixed bug with unclosed paths causing discontinuity at the
start/end point.
Bug: 276466399
Bug: 290254314
Test: integration and unit tests pass
Relnote: PointF parameters changed to Float pairs
Change-Id: Id4705d27c7be31b26ade8186b99fffe2e2f8450e
M graphics/graphics-shapes/api/current.txt
M graphics/graphics-shapes/api/restricted_current.txt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicShapeTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonMeasureTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/RoundedPolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/ShapesTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/TestUtils.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Cubic.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/CubicShape.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FeatureMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FloatMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Morph.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/PolygonMeasure.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/RoundedPolygon.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Shapes.kt
M graphics/graphics-shapes/src/main/java/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/ShapeEditor.kt
M graphics/integration-tests/testapp/src/main/java/androidx/graphics/shapes/test/MaterialShapes.kt
ap...@google.com <ap...@google.com> #3
PointF was the main (possibly only) mutability issue, marking this as fixed
sg...@google.com <sg...@google.com>
pr...@google.com <pr...@google.com> #4
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.graphics:graphics-shapes:1.0.0-alpha04
za...@yandex.ru <za...@yandex.ru> #5
Hello,
I’m experiencing an issue with the DateRangePicker in Jetpack Compose Material3.
Issue Description
When using DateRangePicker in DisplayMode.Input, entering the same date in both fields (Start and End) and then clicking on the “Start date” field triggers a validation message:
“Invalid date range input”
This message cannot be dismissed when selecting the same start and end date. It makes it impossible for users to pick a single-day range in input mode.
Expected Behavior
The DateRangePicker should allow selecting the same start and end date without showing a validation error, as a one-day range is a valid selection.
Environment
• Compose Material3 version: 1.3.1
• Android Gradle Plugin version: 8.8.0
• Kotlin version: 2.1.10
• Core KTX version: 1.15.0
• Activity Compose version: 1.10.0
• Compose BOM version: 2025.01.01
Steps to Reproduce
1. Open DateRangePicker in DisplayMode.Input.
2. Enter the same date in both “Start date” and “End date” fields.
3. Click on the “Start date” field.
4. The message “Invalid date range input” appears and cannot be dismissed.
Could you please take a look at this issue? A single-day range should be a valid selection.
Thank you!
I’m experiencing an issue with the DateRangePicker in Jetpack Compose Material3.
Issue Description
When using DateRangePicker in DisplayMode.Input, entering the same date in both fields (Start and End) and then clicking on the “Start date” field triggers a validation message:
“Invalid date range input”
This message cannot be dismissed when selecting the same start and end date. It makes it impossible for users to pick a single-day range in input mode.
Expected Behavior
The DateRangePicker should allow selecting the same start and end date without showing a validation error, as a one-day range is a valid selection.
Environment
• Compose Material3 version: 1.3.1
• Android Gradle Plugin version: 8.8.0
• Kotlin version: 2.1.10
• Core KTX version: 1.15.0
• Activity Compose version: 1.10.0
• Compose BOM version: 2025.01.01
Steps to Reproduce
1. Open DateRangePicker in DisplayMode.Input.
2. Enter the same date in both “Start date” and “End date” fields.
3. Click on the “Start date” field.
4. The message “Invalid date range input” appears and cannot be dismissed.
Could you please take a look at this issue? A single-day range should be a valid selection.
Thank you!
sg...@google.com <sg...@google.com> #6
Tested with the latest (e.g. 1.4.0 alpha), and everything works as expected. A single day selection and validation is possible. Also, clicking the start date field after the second one was input works as expected and I don't see a validation error there.
See attached video.
Can you confirm this on the latest library support? Thanks!
Description
DateRangePicker
doesn't allow selecting a range of 1 day (a range starting and ending on the same day). Date range picker fromcom.google.android.material:material:1.8.0
allows 1-day ranges. Another example is the Pixel clock app allows 1-day ranges when pausing alarms. In general this is a valid edge use case.Looks like
DateInputValidator
marks a range like this invalid, but it's unclear if this is on purpose. The code is surrounded with comments that say "Additional validation when the InputIdentifier is for start of end dates in a range input" and "The input start date is after the end date, or the end date is before the start date." which strikes me as something where the intent wasn't to also reject when start date and end date are equal.