During some lab exercises targeting Compose usage ...

# compose

[Oliver.O]

During some lab exercises targeting Compose usage on big screens with lots of Composables, I discovered a scenario where excessive slot table operations were rendering the UI unresponsive for tens of seconds. Maybe of interest to the Compose team? (It's a Desktop/Web/WASM lab application but the slot table is part of Compose runtime, so this applies to other platforms, too.) Details in 🧵.

[Oliver.O]

So I'm creating a grid of 50x50 cells (that's 2500 in total). Each cell contains a simple single-digit counter. Animations can be switched on and off for all cells simultaneously. To do so, each cell changes its configuration between
• Text or
• AnimatedContent surrounding a Text.
If I do this as usual, the switch between non-animated and animated grid makes the UI unresponsive for up to 18 seconds (Desktop), mainly due to excessive slot table updates. Once I hide the grid at switching time until the next recomposition, those times drop to less than 4 seconds. I wonder if this is 'as expected' or if the Compose team might be interested in optimizing the current slot table design to speed up patterns like this.

The complete application is at https://github.com/OliverO2/compose-counting-grid.
Analysis details are available in SwitchingAnimationVariants.md.

The original discussion started here: https://kotlinlang.slack.com/archives/C01F2HV7868/p1661276144118359?thread_ts=1660234424.503779&cid=C01F2HV7868

[Oleksandr Karpovich [JB]]

cc: @jim @Chuck Jazdzewski [G] JFYI

[Chuck Jazdzewski [G]]

@Oliver.O Can you submit a bug with the above repository linked to it?

As for telling compose to throw away a composition and rebuild it from scratch, that is one of the uses of the key composable. Surround the composition with key and change the key any time you want to force compose to recompose the entire tree.

[Oliver.O]

@Chuck Jazdzewski [G] Sure, I can submit a bug if that helps to keep track of it. The key thing has been tried (by me and others) and did not change the timing. The underlying problem seems to be that the 'old' grid remains in place until the 'new' one has finished composing and key does not change this, even if passed an incrementing counter on each change.

[Oliver.O]

https://issuetracker.google.com/issues/246751843