[AussieWog93]

I'm not a graphics programmer, and don't understand the specifics of how a modern GPU works.

I can state from experience that using Dear ImGui over Qt massively sped up the application we developed (Media player with non-trivial UI that decoded RAW video in real-time using CUDA/Metal/OpenCL). Framerate increased by around 10%, and there was no longer any significant difference between the consumer-oriented software and an internal engineering tool that was literally nothing but an SDL window and some direct API calls.

Perhaps caching was performed driver-side, or perhaps maintaining indexing is not a huge issue on modern GPUs. I couldn't tell you, honestly, but I saw the performance gains with my own eyes. Entire UIs would chew up less resources than a blank QWindow.

[theamk]

I think "media player" is one of the best cases for ImGUI's, as they whole frame changes every time.

The RMGUIs (should?) be much more efficient when the contents are both hard to render and don't change much -- think large amount of styled text, or detailed SVG diagram, or a graph.

(and blank QWindow consumes 0% CPU when there are no screen updates -- this would be hard to beat with IMGUI's even with the best GPU)

[AussieWog93]

(You're 100% right about the QWindow - it's nested layouts that cause it to shit a brick, and even then only on resize)

[kuraja]

> I saw the performance gains with my own eyes. Entire UIs would chew up less resources than a blank QWindow.

I already mentioned this: "many RMGUIs have heavy styling, visually incomparable to their IMGUI counterparts, which makes the average RMGUI far heavier". Dear IMGUI will be faster than the average RMGUI implementation. It's doing way less work. In addition to being cleaner internally.

For simple use cases, Dear IMGUI behaves like an RMGUI internally. (flohofwoe mentions this in another thread.) So its only performance impact is some minor caching overhead, which is far smaller than extra GPU work.