Hacker News Reader

Comment by dthul | Hacker News Reader

I think it refers to the fact that in an immediate mode GUI you adjust the application state while you render the page, meaning that the part of the screen which you rendered before the state was updated shows the old state, while the part of the screen which you rendered after the state was updated shows the new state. The screen is basically "torn" between two or more states and you need to draw another complete frame to bring it back in sync. Not a problem in a game where you redraw everything at 60fps anyway, but not so good for a classical GUI toolkit.

Edit: I guess you could partially solve this problem by double-buffering the application state, so during the first draw you update a state copy, and during the second draw you use the updated state. You won't get any "tearing" but you still need to draw twice.

View on HN

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.

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.

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.

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

Reply on news.ycombinator.com