https://kotlinlang.org logo
#compose
Title
# compose
a

alxdthn

11/02/2023, 5:38 PM
Hello, my simple implementation with
rememberInfiniteTransition
and
Modifier.drawWithContent
already exceeds 16.67ms. Is this intended, or am I doing something wrong?
a

ascii

11/02/2023, 5:54 PM
Release build or debug? And have you tried lazy-delegating
animation
with
by
instead of = and .value?
a

alxdthn

11/02/2023, 6:58 PM
Yes, release. with
by
the same
a

ascii

11/02/2023, 7:29 PM
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

alxdthn

11/02/2023, 7:37 PM
I moved
rememberInfiniteTransition
outside, but still got the same result. It seems like every tick of
InfiniteTransition
blocks the render thread.
I noticed that the behavior changes when switching (re-subscribing to the
animatedAlpha
state).
Untitled.kt
s

shikasd

11/02/2023, 10:25 PM
cc @Nader Jawad
n

Nader Jawad

11/02/2023, 10:33 PM
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

alxdthn

11/02/2023, 11:17 PM
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
.
e

ephemient

11/03/2023, 5:33 AM
I'd expect
Copy code
Box(
  modifier = Modifier
    .size(72.dp)
    .graphicsLayer { alpha = animatedAlpha }
    .background(Color.Red)
)
to perform better
a

alxdthn

11/03/2023, 8:23 AM
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

ascii

11/03/2023, 8:57 AM
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

alxdthn

11/03/2023, 10:37 AM
@ascii Could you share zip with full project?
s

shikasd

11/03/2023, 2:18 PM
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

Sergey Y.

11/03/2023, 2:27 PM
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

ascii

11/03/2023, 2:33 PM
@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

alxdthn

11/03/2023, 2:38 PM
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

ascii

11/03/2023, 2:45 PM
Would be a good idea to create an issue and summarize everything there. Deps:
s

Sergey Y.

11/03/2023, 2:59 PM
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

ascii

11/03/2023, 3:01 PM
Nice, starred! You could also use https://androidx-perf.skia.org/e/ with specific test queries.
😅 1
s

s3rius

11/05/2023, 3:15 PM
@Sergey Y. That's pretty nice! I suppose the project is dead?
s

Sergey Y.

11/05/2023, 3:18 PM
@s3rius what project are talking about?
s

s3rius

11/05/2023, 3:37 PM
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

Sergey Y.

11/05/2023, 3:43 PM
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.