Hacker News Reader

Comment by exDM69 | Hacker News Reader

You will always get page tearing with ImGui (this library and any others). There are mitigations and workarounds but the issue is fundamental to the paradigm.

Consider this trivial counterexample:

    int counter = 0;
    label("count: %d\n", counter);
    if(button("increase")) { counter += 1; }
    label("count: %d\n", counter);

This is, of course, a silly little example but the same issue will arise in many practical use cases and would be much more complicated.

Most applications "solve" this by rendering new frames continuously, so the inconsistent state is only shown for one frame and will quickly disappear. This, however, has terrible power consumption implications if nothing of interest is occuring on the screen.

View on HN

Sorry, I thought that "page tearing" is something else. For example that It has to decide if the scroll bar will be drawn or not. And it has to make that decision before it starts drawing layout items because there can be an item which expands from left-side to right-side(dynamic layout), so the finalLayoutWidth = originalLayoutWidth - scollBarWidth. Then it can compute item's sizes and draw them. My solution is to save maximum layout size from previous frame.

SkyAlt would "solve" your example by quickly redrawing the frame. The power consumption is good because it's redrawing only when the key is pressed or the mouse is moving, otherwise one frame every two seconds, so CPU is most of the time under 1% and my 3.6GHz CPU is running on 1.4GHz.

That looks more like coupling the state with the UI. You could try refactoring your code in an MVC/MVVM style like react such that the state isn't being modified during a UI draw. That sort of out-of-sync issue can happen even with retained mode UIs. I wouldn't say it's fundamental to the paradigm that you intersperse your business logic into your UI. Granted at large scales basically any UI framework falls apart.

That's how normally you write "imgui" style of app - that's the whole idea - you on purposes couple state+behavior+ui in one piece - e.g. if(checkEvent()) drawSomething(); else drawSomethingElse();

Two label that should have the same value are normally one too many, but if they are needed it is often possible to order them properly...

    //initialization
    int counter=0;
    //each frame
    label("count: %d\n", counter);
    label("count again, in case you missed the other label: %d\n", counter);
    if(button("increase")) { counter += 1; }

or, if the order of widgets is constrained, to buffer values:

    //initialization
    int counter_old=0;
    int counter_new=0;
    //each frame
    counter_old = counter_new;
    label("count: %d\n", counter_old);
    if(button("increase")) { counter_new = counter_old+1; }
    if(button("decrease")) { counter_new = counter_old-1; }
    label("count again, in case you missed the other label: %d\n", counter_old);

So this is complexity you normally don't need with other UI approaches. And now would become a "pattern" that needs to be followed.

Reply on news.ycombinator.com