Hello, my simple implementation with

rememberInfiniteTransition

and

Modifier.drawWithContent

already exceeds 16.67ms. Is this intended, or am I doing something wrong?

Release build or debug? And have you tried lazy-delegating

animation

with

by

instead of = and .value?

Yes, release. with

by

the same

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.

I moved

rememberInfiniteTransition

outside, but still got the same result. It seems like every tick of

InfiniteTransition

blocks the render thread.

cc @Nader Jawad

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

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

.

I'd expect

Box(
  modifier = Modifier
    .size(72.dp)
    .graphicsLayer { alpha = animatedAlpha }
    .background(Color.Red)
)

to perform better

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

.

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).

@ascii Could you share zip with full project?

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

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.

@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

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

Would be a good idea to create an issue and summarize everything there. Deps:

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.

Nice, starred! You could also use https://androidx-perf.skia.org/e/ with specific test queries.

@Sergey Y. That's pretty nice! I suppose the project is dead?

@s3rius what project are talking about?

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.

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.