Provide a warm-up API like flutter engine?

[wtfisthatzzz]

I added a Compose screen to my ios app. When I enter the Compose screen for the first time, there will be some noticeable lag. Perhaps providing a warm-up API similar to flutter engine can solve this problem?

[MatkovIvan]

Hi there,

We're already discussing this topic internally, but anyway thanks for bumping this here.
Also, I have to note that we're doing performance related investigations now and it was not a single option to improve the situation on our table. We'll keep you updated.

Related links regarding shader cache in flutter/skia:

• https://docs.flutter.dev/perf/shader
• https://skia.org/docs/user/sksl/

[tafelnl]

What about Impeller? https://docs.flutter.dev/perf/impeller Or isn't it abstracted in a way that it's usable outside of Flutter?

[tafelnl]

Also as far as I am aware, for Android a different approach is being used. The UI is not drawn on a canvas but with Kotlin Compose instead, so it will be Views and not drawings on a canvas (my understanding at least, because I couldn't really find much documentation about this, and I'm a newbie here). On iOS skia is used to draw stuff on a canvas.

Why not go for a more consistent approach and render elements using UIKit? That's what Reactive Native does. And - more similarly - that's what Redwood does. It seems like a more sensical approach to me.

[elijah-semyonov]

Compose is not responsible for rendering, Compose UI is. Composition is in fact a tree, built on top of nodes emitted by composable functions. In case of Compose UI it's a tree of LayoutNode containing layout, input events logic and aware of how to render itself into implementation of Canvas interface. We use Skia, but you can roll your own solution.

Building rendering on top of UIKit from Compose UI is non-trivial, because Canvas interface (which is tightly coupled with Compose UI expectations) sets up requirements, which are next to impossible to fulfil using UIKit capabilities (such as using arbitrary shader for specific geometry area during the rendering loop).

Redwood uses a tree of own Widget nodes, which resolve into native UI. (Similar to how SwiftUI resolves to watchOS, iOS and macOS SDK specific UI hierarchies).

Platform abstracted node type
Android node type
iOS node type

[okushnikov]

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.