"immediate mode" is what they call it.
I call it "lazy stupid".
"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.