what would be the most simple infinite loop for an...

# compose

[Adriano Celentano]

what would be the most simple infinite loop for an infinite animation ? is it possible to animate without reading a state ?

[nickbutcher]

Just landed: https://android-review.googlesource.com/c/platform/frameworks/support/+/1545247/2/compose/animation/animation-core/src/commonMain/kotlin/androidx/compose/animation/core/InfiniteTransition.kt#179

Cc @Doris Liu

[Adam Powell]

That's still reading changing state though

[Adam Powell]

I'm curious what motivated the question about animation without reading state

[Doris Liu]

If you'd like to minimize the state reads, you could consider the coroutine-based animations. The simplest is suspend fun animate(...) : https://developer.android.com/reference/kotlin/androidx/compose/animation/core/package-summary#animate. But even this has a bunch of state reads (of the internally created states). I'd be curious what's the motivation for that preference as well. 🙂

[Adriano Celentano]

Im a bit ashamed to show my hacky game of life code 😅
https://gist.github.com/AdrianoCelentano/c65c58a65b63489821777dba042633cb
• I have a some top level properties, which hold a Grid of Cells
• a Cell can be alive or dead
• each round i need to refresh the alive/dead state of each cell and when each cell state was updated draw each cell again
my hacky idea of doing it was just to increase the round count infinitely, but i didnt need to read the round count state anywhere. (although updating my cell grid state in the in the composable functinon is probably even more hacky and causes to many updates 😅)

Will fix it and put my cell grid state in a compose state. I think this coroutines based animation will help me, to update my cell grid state. Will write here again if it worked out

[Adriano Celentano]

Made this video so u can imagine how it looks, with the currrent implementation ☝️

gameOfLife.mp4

[Adriano Celentano]

so this works fine, it just doesnt give me a delay in between each draw (which actually seems fine in my case)
I could make the delay timing myself via coroutines, but i thought i should use an AnimationClock somehow.

LaunchedEffect(Unit) {
                    animate(
                        initialValue = 0f,
                        targetValue = 1f,
                        animationSpec = infiniteRepeatable(
                            animation = tween(1000, easing = LinearEasing),
                            repeatMode = RepeatMode.Restart
                        )
                    ) { _, _ ->
                            cellGrid.value = calculateNextGrid(cellGrid)
                    }
                }

[Doris Liu]

so this works fine, it just doesnt give me a delay in between each draw (which actually seems fine in my case)

Glad you gave it a try! 👍 How would you like the delay to work in your case?

I could make the delay timing myself via coroutines, but i thought i should us an AnimationClock somehow.

withFrameNanos/Millis is the new AnimationClock. If you need to manipulate the timeline of an animation, you could go one level lower and use the combination of withFrameMillis + TargetBasedAnimation . That would give you more control with more code. 🙂 This combo is actually the implementation under the hood for all compose animation APIs (that manage their own lifecycle).

[Adriano Celentano]

super thank you 🙏 will give it a try

[Adriano Celentano]

my idea was to have sth like this draw() -change state - wait 300ms - draw() - ….

[Doris Liu]

As in, draw every 300ms (i.e. show change at the rate of ~3fps)? For that you could either animate during that time and not draw, or use the combo suggested above to update the animation once every 300ms. The latter is more efficient. 🙂

[Adriano Celentano]

is there sth bad about this approach ?

LaunchedEffect(Unit) {
                    while (true) {
                        cellGrid.value = calculateNextGrid(cellGrid)
                        delay(300)
                    }
                }

[Doris Liu]

That looks fine. Since the calculation is fairly light, the vast majority of the time in the loop is waiting on delay , which is cancellation cooperative. Wouldn't hurt to make it while(isActive), but not super critical.

[Adriano Celentano]

i see that makes sense thx 👍