Dear ImGui – Bloat-free graphical user interface library for C++

Re:Dear ImGui – Bloat-free graphical user interface library ... by Torkel on Wednesday November 04, 2020 @07:22AM (#24988356)

I use ImGui for gui in a user-facing app that is "large-ish" (~500k LOC maybe). When removing items from lists etc I used to keep drawing non-removed items in the list so the user would not see a "glitch". But I realized it is not necessary. Just cut it short. The user can only take one action per frame from mouse click or button press etc. It's totally fine to render one frame a bit "strange" when someone deletes or adds to a list.

There is no problem in redrawing everything from state every frame. There is no problems in having "half frame be old state" - even at 30 fps it is not noticeable.

We use a separate update() and gui() path though. So all entities will get an update opportunity even if the gui is hidden. And state is kept in a config that is beautiful to use... Maybe the issues here comes from not having those parts.

[ Parent | on HN ]

Re:Dear ImGui – Bloat-free graphical user interface library ... by ska on Wednesday November 04, 2020 @11:55AM (#24990728)

I think their point was that you can't do this without committing to redrawing all the time at a reasonably high rate, which has its own set of problems.

[ Parent | on HN ]

Re:Dear ImGui – Bloat-free graphical user interface library ... by DonHopkins on Wednesday November 04, 2020 @12:22PM (#24991013)

Like if you have to concatenate string to make labels (and then parse and measure and format and re-flow text), you end up generating a lot of garbage and memory management and pointless recalculation in the main loop.

[ Parent | on HN ]

Re:Dear ImGui – Bloat-free graphical user interface library ... by Torkel on Wednesday November 04, 2020 @06:27PM (#24994135)

Yes, for sure there is some overhead in this. I checked in Tracy now and with a lot of gui open, using many custom labels etc, it takes on the order of 150-200 us to do that part of the gui. Issuing the GL draw list commands takes some time too, but not too much. I think the expectation is that it is expensive for real, but it turns out that ImGui is actually quite cpu-time-cheap. And a "modern" electron based app gui has a whole different set of overheads, so it not like all alternatives are overhead-free wonderlands..

[ Parent | on HN ]