Nostr Web Client

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.

Vitor Pamplona 5mo ago

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.

Reply to this note

Please Login to reply.

Discussion

jb55 5mo ago

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

Vitor Pamplona 5mo ago

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

jb55 5mo ago