https://kotlinlang.org
Join Slack
From a performance perspective, how horrendous is it to have `Layout { }` invoked every frame? Espec...
# compose
c
From a performance perspective, how horrendous is it to have 
Layout { }
invoked every frame? Especially with lots of temporary collections being created with lines like
Copy code
val placeables = measurables.map { it.measure(constraints) }
z
I think there’s some guidance that it’s best to avoid animating layouts when possible. But if you do just need to animate a layout, they’re generally cheap enough in compose that it might be fine. In particular, compose layouts (at least the basic ones) are less expensive than view layouts. It also might be possible to avoid both recomposing and invalidating the layout on each frame, but that’s probably not worth bothering to do unless you’ve got evidence that that’s what’s causing jank.
👋 1
c
I’m currently making some real hacky code where I essentially want to wire up 
Layout
to Box2D and have composables bounce off each other 😅 Ideally with an API that looks something like
Copy code
Physics {
  Button()
  Text()
}
z
I think it would be better to do this with graphicsLayer offsets - that way you’re just moving hardware layers around and not triggering layout or draw passes on each frame, if I understand correctly.
And you’ll want to use the lambda version of graphicsLayer not the parameter one
c
Oooo, interesting 🤔. Any limitations on the number of graphics layers that can be around at once?
z
I have no idea. At some point even if there’s no hard limit I’d expect the overhead would start to show as well, and I’m not sure if you’d hit that sooner with layers or layouts. Would be fun to implement both then just keep adding children until you notice frames dropping and compare.
c
Definitely sounds like 
graphicsLayer { }
is the place to start! Thanks for the help yet again
If I wanted to aim for the API to look like what I mentioned above, is there a way I could cheekily update the modifiers of every composable passed in?
a
Also if your layout is invoked very often, using compose versions of list utils (e.g. 
fastForEach
, 
fastMap
) from 
ui-util
module can at least reduce the number of temporary objects.
a
When you want to be manipulating more than one child element relative to each other with one source of truth performing the coordination, 
Layout
is the way to go. In the placement block you can do 
placeable.placeWithLayer
which is identical to giving that child a 
graphicsLayer
to add whatever additional effects you like.
z
Oh right I always forget about that
c
Early 
placeable.placeWithLayer
experiments are promising 😄
Screen Recording 2021-09-15 at 13.55.07.mov
🤩 3
😄 1
z
Haha I love it!
Angry Buttons
a
That's pretty great
s
Wait this is actually hilarious and amazing at the same time, I have never seen anyone else share something similar to this before mind blown
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by