A modern programming language that makes developers happier.

kotlinlang

is compose layout phase and state update multi-threaded?

They are not. It's something we've been talking about doing for a long time though

<@U3JQ35YQK> Thanks let me know it's something the team care about. Currently i made Compose(Skia) render inside Minecraft, also other a few app/game using opengl. For non-games, compose is enough. But for games where require high fps. Such as Minecraft, compose state machine and layout (average app, not a todo list) took longer than the 3D world to render, because state update is limited in one-thread and layout is always blocking the render.

It's something we care about, but I can't make any promises on when/if it'll haopeb

Note that there's no reason for a compose app to block Minecraft's renderer 

The api provide explicit made layout before render.

Automatically choosing at what point to move to a different thread would be difficult.

If you have each thread render to a bitmap and then overlay them on top of each other at the end... I wonder how well that would perform.

And state update is bound to one thread. (I remember saw their are comments about multi thread)

<@U1ZQ36CJD> That's not how it would work

Why couldn't you run compose in a separate thread and only update the texture in Minecraft when that thread is done?

The app use Minecraft game states, render is on main thread, state update is explicitly called before render and layout. 

Plus network request, game events, incoming source is from different threads. Compose desktop also use awt(it can be replaced, but rn is depend on awt, I create awt wrapper for OpenGL )

Right now I just remove state completely in my compose app, it will make the app “recompose”  every time , put hope on jvm’s jit

<https://github.com/JetBrains/compose-jb/issues/2005|https://github.com/JetBrains/compose-jb/issues/2005>

Note that Minecraft always renders, not like Compose which only renders on need.

I experimented some time ago and it turns out that updating states in a different thread is not a problem, but applying the changes should be always on the same thread. No idea how the internal works.