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