Fixed
Status Update
No update yet.
Comments
sg...@google.com
gk...@ramp.com
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
sg...@google.com
PointF was the main (possibly only) mutability issue, marking this as fixed
gk...@ramp.com
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
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit f09ae412b90caf84bc36b55b0d4ef75b6b6503a8
Author: Shalom Gibly <sgibly@google.com>
Date: Wed Feb 14 17:03:33 2024
Ensure buttons visibility at the DatePickerDialog
Wrap the content with a Box and Modifier.weight = 1 to ensure any
confirm or dismiss buttons are visible when the dialog wraps a
DateRangePicker, or when large fonts are displayed on smaller screens.
Bug: 325107799
Bug: 277768544
Test: Verified screenshot tests and manual tests
Relnote: "Ensure that the DatePickerDialog displays its buttons when
nesting a DateRangePicker or when displaying any type of date picker on
small screens with larger fonts."
Change-Id: Ie4758e82b94eb2d5e448a973c550302ff1601f3f
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/DatePickerDialog.android.kt
https://android-review.googlesource.com/2964508
Branch: androidx-main
commit f09ae412b90caf84bc36b55b0d4ef75b6b6503a8
Author: Shalom Gibly <sgibly@google.com>
Date: Wed Feb 14 17:03:33 2024
Ensure buttons visibility at the DatePickerDialog
Wrap the content with a Box and Modifier.weight = 1 to ensure any
confirm or dismiss buttons are visible when the dialog wraps a
DateRangePicker, or when large fonts are displayed on smaller screens.
Bug: 325107799
Bug: 277768544
Test: Verified screenshot tests and manual tests
Relnote: "Ensure that the DatePickerDialog displays its buttons when
nesting a DateRangePicker or when displaying any type of date picker on
small screens with larger fonts."
Change-Id: Ie4758e82b94eb2d5e448a973c550302ff1601f3f
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/DatePickerDialog.android.kt
sg...@google.com
Thanks. I believe that the design intent was to have the Date-Range-Picker in a full screen, and not in a dialog. But since we still allow placing it in a dialog (makes sense to me:)), there may be some adjustments that will need to be done to better support it visually.
Also, just pushed a fix for the main issue here and it should be available at the next 1.3.0 alpha release.
gk...@ramp.com
Thanks so much for fixing! I wasn't aware that DateRangePicker was intended to be used in a full screen, as it doesn't included confirm / cancel buttons by default it made sense to me to wrap it in a DatePickerDialog which does provide those. Appreciate your help here!
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.3.0-alpha02androidx.compose.material3:material3-android:1.3.0-alpha02androidx.compose.material3:material3-desktop:1.3.0-alpha02
da...@gmail.com
I'm still having this issue but thanks for the weight workaround.I load dependencies via "androidx.compose:compose-bom:2024.06.00". The documentation states that the material3 dependency is stuck on version 1.2.1, and the other 2 are not there at all. Should I add them and/or upgrade them? And in which BOM version are these fixes planned to be added?
da...@gmail.com
When I change the component's mode, I no longer need the weight, since otherwise the dialog is bigger than content inside. When I change the modifier, a lag appears when the picker mode has changed, but the dialog box has not changed yet. How did you deal with this?
Description
Jetpack Compose component used: DateRangePicker
Android Studio Build: Android Studio Build: Android Studio Hedgehog | 2023.1.1
Build #AI-231.9392.1.2311.11076708, built on November 9, 2023
Kotlin version: 1.7.20
Material3 version: androidx.compose.material3:material3:1.2.0
If you put a DateRangePicker within a DatePickerDialog, the Confirm button seems to be hidden by default, I think being overlapped / pushed off by the DateRangePicker content. Manually adding a Modifier.weight(1f) to the DateRangePicker seems to fix this. Probably this Modifier should be included by default within the SDK to avoid this problem.
Sample Code:
```
class MainActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
ComposeTestV2Theme {
// A surface container using the 'background' color from the theme
Surface(
modifier = Modifier.fillMaxSize(),
color = MaterialTheme.colorScheme.background
) {
DatePickerTest()
}
}
}
}
}
@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun DatePickerTest() {
val state = rememberDateRangePickerState()
Column {
DatePickerDialog(
onDismissRequest = {},
confirmButton = {
TextButton(onClick = { Log.d("DatePicker", "Confirm button clicked") }) {
Text("Confirm")
}
},
) {
DateRangePicker(
// modifier = Modifier.weight(1f),
state = state,
)
}
}
}
```