oh, i got confused, yes, exactly, immediate mode is easier to get right it only gets glitchy when you overload the cpu - when you are writing a multithreaded app and you have one thread doing the frames you can simply make it exclude any other work using a mutex and that can at least avoid you tampering with the frames

back in the old days on the amiga there was an interrupt and the interrupt called your render code and any logic had to wait until that was done

i'm amazed how long it's taken for well established conventions that were devised by apple and amiga devs have taken to become well understood and used, i mean, ffs i'm literally talking about 35 years ago i wrote a flicker free sprite on a 700hz 8 bit cpu running interpreted basic ... and i'm supposed to believe it's difficult??? more like most programmers are retarded

hold on, immediate mode GUI code means you create logic trees that decide how to paint the display, as code, with branches and switches and if/then/whatever stuff

they have to be multithreaded, or at least the render thread needs to interrupt everything else the app is doing or you lose fps

the tricky thing is sometimes needing to do secondary processing in between painting, like with scrolling and physics and animations, these need to sometimes be computed before you do the paint or the variability of the time required to do the compute can impact your frame rate