Status Update
Comments
ro...@gmail.com <ro...@gmail.com> #2
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
ma...@google.com <ma...@google.com>
on...@aol.com <on...@aol.com> #3
sg...@google.com <sg...@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
on...@aol.com <on...@aol.com> #5
We tried both. It's a bit better in release version but not good enough for production use.
We tested on physical Pixel 3a with API 32.
sg...@google.com <sg...@google.com> #6
Could you provide us with a minimal code that showcase this issue. It can be very helpful!
sg...@google.com <sg...@google.com> #7
Might be related to
Will keep this one open for now until the fix is merged and pushed for the next alpha.
ma...@google.com <ma...@google.com> #8
Possibly fixed/duplicated by
sg...@google.com <sg...@google.com> #10
Oh.. Actually the fix was for exitUntilCollapsedScrollBehavior
. Reopening.
sg...@google.com <sg...@google.com>
ap...@google.com <ap...@google.com> #11
Project: platform/frameworks/support
Branch: androidx-main
Author: Shalom Gibly <
Link:
Remember top and bottom app bar behaviors
Expand for full commit details
Remember top and bottom app bar behaviors
Update the exitAlwaysScrollBehavior and pinnedScrollBehavior to be
remembered across compositions.
This follows that was previously done at the enterAlwaysScrollBehavior.
Bug: 207957336
Test: Manual
Relnote: "Scroll behavior functions for top and bottom app bars now
return a remembered behavior to perform better across recompositions."
Change-Id: I0fdbe6e2ffb01d97b4c57d3a41a76f8531a2d72a
Files:
- M
compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/AppBar.kt
Hash: c41d112fa72e1a0dc445a90cfc83306868c6aa31
Date: Fri Nov 15 14:02:50 2024
Description
val scrollBehavior = remember { TopAppBarDefaults.enterAlwaysScrollBehavior() }
Scaffold(
modifier = Modifier.nestedScroll(scrollBehavior.nestedScrollConnection) // this makes scroll very slow and leggy
){
LazyColumn(
content = {}
)
}