Well, I don't know how Swift works. On Compose the rendering of simpler apps is usually <1ms unless there is some animation (which uses immediate mode) or re-measurement of something (like a link turning it into a preview - which is retained), then it's like 3ms or so to compute. But the most important part is that there is no system call into the graphics pipeline unless it's really needed.

Frankly it all depends on how many things you want to run at the same time. There is only one CPU for everything. That's why to me 6ms seems like a lot for just passing through the rendering stack and showing things on screen.

If this was on the desktop back in the 2000s, that time would have made me switch to retained mode right away. 6ms rendering as game dev is fully unacceptable time because of the other things (like physics) that the game needs to do, which were (are?) usually heavier.

Reply to this note

Please Login to reply.

Discussion

why wouldn't you want the graphics stack involved? its much more efficient at getting pixels on screen at high fps. this enables lots of cool usecases like 3d ui elements (like dave) and visualizations. blitting with CPUs to patches on the screen is so 90s tech, it also feels slow because CPUs suck at rendering. anytime you need some global animation you have to recompute everything anyways. might as well just go through the fast path.

I am not sure I understand. I can use the full graphic stack via the usual Compose library, in retainer or immediate mode, including custom shaders if I want so that the animation doesn't use CPU cycles (and avoids system calls while doing so).

Aren't you loading profile images as textures in the graphics pipeline? It would be crazy to send the pixels of each profile every time the screen needs to change. That alone is already a small "retainer mode".

I agree that CPUs suck for rendering. That's why the retainer mode moves everything to the GPU itself. Frankly, to me the CPU shouldn't even touch the UI. The app just sends a graph of 3D objects and the GPU sorts out what has changed and renders it with the appropriate view boundaries.

Regardless, If you go for more complex 3D renderings, you will need a retainer mode at some point. There is no way to redraw a full 3D scene fast enough.

egui of course maintains packed texture atlases of loaded textures. you don't need to upload that every frame.

at the end of the day,it comes down to empirical performance of the resulting app. all these retained mode ui $100 android phone are slow as balls. this immediate mode app is the only thing that is usable. I will take empirical results over hypotheticals

Frankly, I don't think the UI being slow has anything to do with the immediate or retainer mode choice. Especially because Compose is partially in immediate mode as well. I think many of the animations of most apps are still in immediate mode.

To me it is about thread prioritization, which is usually terrible in most apps, sys calls that are usually super slow, and easy libraries that need to do a lot of work to render.

For instance, Compose's Text element is a full HTML renderer. The text devs pass to it needs to be parsed before rendering. That doesn't need to be there for most apps, but it is. Things like that is where CPU cycles are going, not the UI mode choice. Compose's UI graph walk to figure out what changed for rendering is indexed, so it easily goes into the

k