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.

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.