4 ms·

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 fra

by mappu 1mo 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.

winrid 1mo ago
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.
- IshKebab 1mo ago
  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.
  - winrid 1mo ago
    as a side note I absolutely hated writing UIs in egui. It is a really nice framework, but the iteration times were painful.
mijoharas 1mo ago
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?
- deleted 1mo ago
  [deleted]
deleted 1mo ago
[deleted]
earcar 1mo ago
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.
- demibabs 1mo ago
  “Claude, why did you use an immediate mode framework?”

by mappu 1mo 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.

winrid 1mo ago

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.

IshKebab 1mo ago
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.
- winrid 1mo ago
  as a side note I absolutely hated writing UIs in egui. It is a really nice framework, but the iteration times were painful.

mijoharas 1mo ago

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?

deleted 1mo ago
[deleted]

deleted 1mo ago

[deleted]

earcar 1mo ago

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.

demibabs 1mo ago
“Claude, why did you use an immediate mode framework?”