https://kotlinlang.org logo
Join Slack
Powered by
Hello, my simple implementation with `rememberInfi...
# compose
a
Hello, my simple implementation with 
rememberInfiniteTransition
and 
Modifier.drawWithContent
already exceeds 16.67ms. Is this intended, or am I doing something wrong?
Screen Recording 2023-11-02 at 20.31.46.mov
a
Release build or debug? And have you tried lazy-delegating 
animation
with 
by
instead of = and .value?
a
Yes, release. with 
by
the same
a
There's two things you can do: • remember the animationSpec because that object's being created practically every frame right now. • Migrate to Modifier.Node if possible? There aren't any docs for it yet, but look at other built-in modifiers to see what you can do with it.
a
I moved 
rememberInfiniteTransition
outside, but still got the same result. It seems like every tick of 
InfiniteTransition
blocks the render thread.
Untitled.kt
I noticed that the behavior changes when switching (re-subscribing to the 
animatedAlpha
state).
Screen Recording 2023-11-02 at 23.56.55.mov
Untitled.kt
Untitled.kt
s
cc @Nader Jawad
n
Hard to tell without seeing the full snippet but it looks like there's a composed modifier being used here which adds some overhead. There was the recent Modifier.Node migration that allows for better reuse of modifier internals across frames
a
This is the complete code of an activity in a clean project with all suggested optimizations enabled. It doesn’t use 
Modifier.composed
. Also 
Modifier.drawWithContent
is implemented based on 
Modifier.Node
.
Untitled.cpp
e
I'd expect
Copy code
Box(
  modifier = Modifier
    .size(72.dp)
    .graphicsLayer { alpha = animatedAlpha }
    .background(Color.Red)
)
to perform better
a
In my case, I specifically need the implementation of 
Modifier.drawWithContent
because the snippet only reflects the idea embedded in the implementation of my solution. But it does’t matter. Regardless of how I implement it, whether using 
Modifier.graphicsLayer
or 
Modifier.alpha
, the result remains the same. Therefore, I assume the problem lies somewhere in 
InfiniteTransition
.
a
This is what I get with the exact same code as https://kotlinlang.slack.com/archives/CJLTWPH7S/p1698967028437249?thread_ts=1698946711.738549&cid=CJLTWPH7S (except the theme of course).
a
@ascii Could you share zip with full project?
s
Feel free to create an issue and share your findings there, I feel like you'll get a higher chance for it to be addressed
s
No idea why it so unstable
There are two potential reasons for what you're seeing: 1. You're getting a performance boost because the app is fully compiled ahead of time (AOT). Sometimes, you might need to restart the app to notice the improvements. (You also, can request full AOT via ADB commands to verify if it is the case); 2. It could also be device-specific. Certain devices, like Samsung, might lower the screen refresh rate if there's no user interaction with screen.
a
@alxdthn I just copied your code into one of my projects as a new activity, set that to be the launch activity, and ran it as a release build. It should behave the same in an empty project too, there's nothing special going on I believe.
Have you tested it on a real device or an emulator?
a
Have you tested it on a real device or an emulator
Both. Also with baseline_profile or not. It remains unstable, similar to what’s shown in this video. It seems to be related to AOT
I requested the project because I wanted to compare the versions of the dependencies and plugins being used. @ascii But I personally don’t believe I will find anything in this.
a
Would be a good idea to create an issue and summarize everything there. Deps:
s
Back in the day, I tested how well Compose performed. The code repository is somewhat old, but at that time, Compose worked quite nicely, and it's still performing well with my current project. https://github.com/desugar-64/android-compose-performance-test/blob/main/android-c[…]/benchmark/benchmark_reports/reports/samsung_sm-g991b/Readme.md https://github.com/desugar-64/android-compose-performance-test/blob/main/android-client/benchmark/benchmark_reports/reports/oneplus_be2029/Readme.md There's a chance you're fighting a phantom menace.
👀 1
a
Nice, starred! You could also use https://androidx-perf.skia.org/e/ with specific test queries.
😅 1
s
@Sergey Y. That's pretty nice! I suppose the project is dead?
s
@s3rius what project are talking about?
s
Ah, sorry. It's the second to last comment, but I didn't see that it's already a 2-days old thread. I was talking about https://github.com/desugar-64/android-compose-performance-test. It'd be interesting to see how the push for performance in Compose 1.5 turned out.
s
No worries. The project isn't entirely dead, but I haven't updated it because I no longer have access to those test devices. To be honest, the androidx.benchmark library has evolved since I last used it, and I would probably need to rewrite many tests and scripts to make it work again. Maybe one day, I will return to the project.
7 Views
Open in Slack
PreviousNext
Powered by