undefined | Better HN

0 pointskuraja5y ago0 comments

> There is literally no downside to using the IMGUI concept

There's a big downside, the performance penalty. For a GUI that renders moderately complex objects, the cost of not caching becomes overwhelming, the equivalent of losing 20 years in GL architecture advances. Pushing the VBO to the GPU each frame is the same as losing indexing. My own application doesn't render at 60 fps in immediate mode.

I find that people who believe that IMGUI is somehow faster than RMGUI are game developers who have been taken in by marketing, because basic knowledge of GPU programming (i.e. what is indexed rendering) is enough to see that this couldn't possibly be true. Their UIs are usually simple enough that the performance penalty is not important. And many RMGUIs have heavy styling, visually incomparable to their IMGUI counterparts, which makes the average RMGUI far heavier.

0 comments

AussieWog935y ago

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.

theamk5y ago

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)

AussieWog935y ago

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

kurajaOP5y ago

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

j / k navigate · click thread line to collapse

0 pointskuraja5y ago0 comments

> There is literally no downside to using the IMGUI concept

0 comments

AussieWog935y ago

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

theamk5y ago

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)

AussieWog935y ago

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

kurajaOP5y ago

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

j / k navigate · click thread line to collapse