Is it re-rendering the whole screen when you move the mouse? Or why is it rerendering that much?
Discussion
Yes it's that weird application architecture that re-renders everything, inspired by games. Forgot what it's called. Weird shit. Rust mobile developers like it because they don't use Android widgets anyways.
"immediate mode" is what they call it.
I call it "lazy stupid".
Immediate mode doesn't need to rerender everything. If that is how the community sees it, they are misunderstanding how immediate mode works. The whole distinction between immediate vs retained is about which component in the tech stack controls the scene/UI, not if things need a full new frame or not. You can render a partial change in the frame in both settings.
When I used to do this stuff, it was all about the overhead of OpenGL function calls. If the overhead is greater than sending the vertex data to the graphics harware (which almost always was), we would switch to retained mode. Basically, we would almost always start in immediate and when the scene/UI gets more complex switch to the retained mode.
i mean sure in theory but thats not how most immediate mode UI libraries are set up. its just easier to repaint everything since its fast enough.
pretty sure the guy who invented the terminology (Casey Muratori) would agree. I don't think I've ever seen an immediate mode library that draws over previous retained frames.
Maybe they need better immediate mode libraries, then. Repainting everything is definitely not fast as repaiting just what's needed, even in today's hardware.
Also, he did not coined the term:
"Excited about the results, I [Casey] reported on the technique to a private mailing list in the fall of 2002. To describe it, I coined the term “Single-path Immediate Mode Graphical User Interface,” borrowing the “immediate mode” term from graphics programming to illustrate the difference in API design from traditional GUI toolkits. I continued to use the technique for several years, until I finally put up a super rough public video describing the basics in 2005".
Immediate mode is has been a term in computer graphics long before him.
GUIs are 100x simpler than game Scenes, so it makes sense to apply immediate mode to GUI design (like the old graphics people used to do), but the GUI itself has severe upperbound limits on what it can do.
you posted a link comfirming he did create the immediate mode ui concept, so I don't see your point. I never claimed he came up with "immediate mode" term from graphics programming.
I would also disagree that game scene are simpler than GUIs. game scenes just need to pump triangles, colors and textures. gpus are great at that.
tesselating a GUI is much more complicated, and you need to be smart about texture atlases for glyphs and images.
maybe immediate mode *graphics* programming was slow, but modern IMUI stacks like egui use modern graphics apis like wgpu/vulkan/metal and are quite fast.
notedeck and damus android will be the fastest and smoothest GUI app on any device you throw at it, even $100 android phones. I think this is proof enough that repainting everything is faster than retained mode diffs.
All I am saying is that he is basing his UI concept in the "Immediate Mode" term from computer graphics, which has always had partial frame rendering. This idea of re-rendering all the frame is not only dumb, it is unecessary. But now I understand why he was so amazed by what Sutherland did in the 70s in the OOP video. Which is good, because you should be able to make Damus Android at least twice as fast as it is today if you get a better UI toolkit.
Well that escalated quickly.
yes it repaints everything in 0.2 to 6ms depending on the cpu, so you can easy hit 140fps stable on any device. since this frame time is very stable, we basically never have FPS dips.
its pretty unintuitive but it is the smoothest app on my computer atm.
why do it this way? it makes building apps way simple. uis are just function calls. no state passed between frames. very easy to animate things.
6ms just to render the UI? That seems like a lot. Are you sure? Does that include also include checks for the difference, updates measurements of where things go, if it needs to update or not? What else is included in this 6ms? If I didn't have 6ms per changed frame because the UI is doing stuff, Amethyst would be fully unusable.
i mean amethyst was taking 1000ms+ to render frames on the same phone (i was getting like 1fps when using the app), so are you sure ?
Yeah, but I am dumb. I am parsing text to render in the middle of the thread and doing 1000s other things while rendering. I have not spent a single second optimizing it for rendering times.
i have the same problem in damus ios, and I have been spending lots of time trying to optimize it. it always spends 100s of milliseconds inside of SwiftUIs retained mode diffing algorithm that I can do absolutely nothing about.
hence why I am now an immediate mode shill. not having "surprise diff" frames that lags your app is nice, even if 6ms seems a lot, its not. the stability is worth it.
I'm running at 1.6ms per frame on my 240hz monitor atm. my frame budget is 4ms for that framerate, so I still have lots of wiggle room.
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.
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
This might help.
