The vast irony of all this is that today interacting/scrolling in Facebook or Twitter is vastly less efficient that a basic graphic app rendering at 60 FPS. Facebook has become _ACTUALLY_ slow to interact with even from a human point of view.

This is a very common problem on modern machines and modern software. Engineers default to putting in so much machination of caches and dirty-flags to avoid redundant processing that they end up making something that does way more work to avoid work than a decent implementation of just blindly doing the work all-gas-no-brakes.

I’m not entirely sure this is true in practice.

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.

Games also require said GPU computing power. Lots of UI may have to conserve power/energy - think about some IoT device that may not even have GPU, and need to use as little as possible energy.

Or smartphones where you want to conserve battery life.

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!

I'm not convinced that redrawing on input events is especially inefficient. No need to redraw continuously.

Indeed, I've got dear imgui working like that and it's the performance is miles above any retained gui. Dear imgui however it is not designed with this in mind. You run into a some issues with timing, handling release events and a few things which normally take 1-3 frames to fully resolve. Things like key repeats are off. It feels more desirable to fork the lib or design an alternative imgui to support long periods of idle time.

Imgui has problems, but this isn't one of them.

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.

> 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.)

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.

> Except that a a retained mode GUI can easily tell that no redraw is necessary and it will be a no-op.

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?

> Your retained-mode GUI framework isn't doing dirty rectangles anymore anyway; it's going to redraw everything anyway.

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.

i plan using it in a data viz app. works great! much better experience than traditional GUI toolkits.