Comment by mappu
6 days ago
If you're focused on lightweight, native and fast, I don't think you should use an immediate-mode GUI toolkit. Why does an app like this need to hit a 60fps framerate? It's not a game.
6 days ago
If you're focused on lightweight, native and fast, I don't think you should use an immediate-mode GUI toolkit. Why does an app like this need to hit a 60fps framerate? It's not a game.
I was surprised to see an immediate mode gui toolkit.
They're great to integrate into a game loop because you control your loop, (and they're a delight to use) but I thought for perf retained mode was the way to go?
Am I missing something? Then again if the bar needing to be beaten is spotify's existing desktop app maybe it doesn't matter?
Most immediate mode does a scene graph diff so it's not that bad
I have a custom IM GUIs based ide thing in C++ that uses like .2% of my 10yo CPU.
Egui doesn't do that. But it's written in Rust and only updates when you interact with it so in practice it's way more efficient than I would have expected.
as a side note I absolutely hated writing UIs in egui. It is a really nice framework, but the iteration times were painful.
Author here. Two reasons I chose an immediate mode UI framework:
1. Latency. A click paints on the next frame, because it sidesteps the stages of a retained mode UI: there's no dirty-marking, no layout and paint passes scheduled for later, no cached visual state that can be stale.
2. Simplicity. The UI is a plain function of app state. There's no retained tree to keep in sync and no invalidation bugs: mutate the state and the next frame shows it.
Yes, the drawback is that you have to watch what a frame costs, but it doesn't repaint at every frame. It paints on input and you can schedule repaints yourself. Fastpotify sits at zero CPU when idle, asks for a few frames a second while a track plays, and runs at full rate only while you scroll.
“Claude, why did you use an immediate mode framework?”