Looks like right now we are not getting 60fps, pho...
# compose
a
Looks like right now we are not getting 60fps, phone Pixel 2 XL.
z
hey, I haven't updated the project to dev05 yet, which has AdapterList
will do soon
and then we can see how much it speeds it up
s
Also the project is in pre-alpha phase. I'm sure the team will focus on performance once the APIs have been flushed out
t
oh nice, i want to try out the adapterlist
a
yeah performance is highly dependent on knowing exactly what you're doing right now since we're not doing a lot of the planned skipping optimizations yet, and even then there's a lot of low fruit optimizations in the critical paths. 60fps is plenty doable if you avoid recomposing the world per-frame so far
πŸ™ 1
and there are a couple of outstanding bugs/unfortunate behavioral interactions that can get you into that recompose the world situation when the same code shouldn't once we're done with it πŸ™‚
ok, took a look at this for fun and moved it to -dev05, swapped out compose-router for just a simple
state {}
for the time being. It's smooth on an emulator
there seems to be a bug with Transition that is keeping the loading rotation animation pulsing and generating frames after the loading screen goes away
πŸ‘ 1
didn't try it with compose-router updated to -dev05 since I didn't feel like messing with gradle too much more, but I'd suspect that it's some pathological behavior in there triggering a lot of work
(the version using -dev04 and compose-router fresh off github basically froze the same emulator on the same laptop)
(not emulator πŸ™‚ )
πŸ‘ 2
a
cool thanks - will check dev05
a
To be clear, it's not just dev05 making a difference here, it's specifics of the app code as well and possibly specifics of the router library used by this app in particular.
Hitting 60fps was not particularly problematic with dev04 either. πŸ™‚
z
Hey @Adam Powell, thanks a lot for diving into it! I'll spend some time trying to find bottlenecks - if you have any ideas where to approach it from, please share, it's much appreciated.
πŸ‘ 1
a
Haven't looked at the router stuff, and I did a bunch of little cosmetics around wrapper to modifier conversions, but one thing I can think of that struck me as potentially very weird was constructing a
transitionDefinition
inside of a composable but outside of a
remember
z
I'll look into it, cheers!
πŸ‘ 1
a
Based on the other thing I noticed with the transition, that may have amounted to a mini-fork bomb of handler messages every time that function recomposed πŸ™‚
z
Speaking of which, I'm not sure I understood it correctly when you wrote about it first. Regarding this: "there seems to be a bug with Transition that is keeping the loading rotation animation pulsing and generating frames after the loading screen goes away" - do you mean bug from compose side, or bug resulting from incorrect usage?
a
Compose side. It doesn't seem to have cancellation due to composable dispose wired up
so kind of a perfect storm. If you create a new transitionDefinition object, the Transition composable thinks you're doing something new and different and so it creates new internal transition state based on it and starts the animation. Since it never disposes and you're using infinite transition definitions... πŸ™ƒ
with that bug fixed you'll still want to
remember
your `transitionDefinition`s based on their inputs, or just declare them as constants, since otherwise you'll basically be starting new animations from scratch all the time and it probably won't give you the visual result you want
there are a few lower level animation APIs coming soon too that might be a better fit for your rotation animations here
z
thanks for explaining, it's really informative!
πŸ‘ 1
a
Update on this: the bug around animation subscriptions was fixed and the fix should be in dev06 next week. https://android-review.googlesource.com/c/platform/frameworks/support/+/1243712 for the curious
πŸš€ 2