It's good for games, but for applications where you're not rendering new frames constantly, the paradigm doesn't seem a very good fit.
It's also very inefficient to continuously redraw, which is not a concern for games, but not in general.
It's also very inefficient to continuously redraw, which is not a concern for games, but not in general.
Games can render huge, vibrant, dynamic 3D worlds at 60fps and increasingly at >120Hz rates. Web browsers lag if a piece of dust falls on the wrong spot.
I agree with you in theory. But in practice retained mode is a mountain range or complexity and doesn’t actually perform better.
I think people dramatically overestimate the cost to perform simple UI layout. There’s no reason that CPU time should be more than 1ms single-thread for most apps. GPU time should be similarly small. Modern smartphone supercomputers are FAST!
Your retained-mode GUI framework isn't doing dirty rectangles anymore anyway; it's going to redraw everything anyway. (Not every frame, but upon receiving an event.) With modern GPUs, redrawing a whole frame is super cheap, even with integrated graphics.
The gain, then, is going to come from not having to rebuild the scene graph every frame. And modern imgui implementations will cache the scene graph+layout anyway, and only rebuild the parts they need to. Which is slightly more CPU-intensive, but not appreciably so.
Except that a a retained mode GUI can easily tell that no redraw is necessary and it will be a no-op.
> With modern GPUs, redrawing a whole frame is super cheap, even with integrated graphics.
It's cheap as in fast, but it's not cheap in power consumption having to wake up the GPU from sleep state to redraw what's already on the screen.
This matters with battery powered devices.
> The gain, then, is going to come from not having to rebuild the scene graph every frame.
Rebuilding a scene graph that's based on CSS-style flexbox layout is REALLY fast. It's a linear time operation in the worst case and a lot of the work can be just skipped if the layout doesn't need updating.
Check out Raph Levien's talk which I linked to in my top level posting. He discusses the implementation details to make this smoking fast.
Text layout is by far the most time consuming operation in rebuilding a GUI scene graph.
The way this is done in the Druid UI library is probably a lot faster than what ImGui does, if you exclude the time it takes to do text layout with HarfBuzz.
All of this is pretty moot point, because the most important factor in performance and battery consumption is not to wake up the GPU to do unnecessary work.
How is that different from imgui exactly? Both dirty rect invalidation and the following redraw skipping is incredibly easy to do (and has been done, see microui)
> Rebuilding a scene graph that's based on CSS-style flexbox layout is REALLY fast. It's a linear time operation in the worst case and a lot of the work can be just skipped if the layout doesn't need updating.
I'm not sure what are the numbers there, but my fullscreen imgui application (You can see it here https://twitter.com/DoctorGester/status/1022147094558269446 and there are views with more complex layouts, rich text rendering, etc) hacked on top of DearIMGUI takes 0.2ms (200 microseconds) per frame, that is including all the logic and submission of commands to the GPU backend. That's before any optimization or multithreading independent views. Do you really get much faster than that?
Does this refer to the one presented in the top-level comment or a retained-mode GUI framework in general (like GTK)? Because it's usually not true for the latter.