3 ms·

Either I'm missing something, or this must be absolutely horrific in terms of performance. Each object draws itself every frame, is that correct? If that's no

Either I'm missing something, or this must be absolutely horrific in terms of performance. Each object draws itself every frame, is that correct? If that's not true, then you must spend a huge amount of time trying to figure out which objcts need to be drawn and which objects don't. Indeed this is the very work that most event driven GUI frameworks try to spare the developer from having to deal with, because the problem is not trivial. As I said, maybe I'm missing something, in which case I would love for someone to enlighten me...

seanmcdirmid 14y ago
For small UIs in games that run at frame rate, the performance is probably competitive to (if not better than) a retained UI. They are probably redrawing their screen on each frame anyways, while retained has its own memory/compute overhead to consider. Now, there is some point where the immediate mode UI becomes uncompetitive with retained; if you have a lot of complex/nested widgets for example, or you care about power consumption for a mostly static UI.
ajuc 14y ago
In games and other interactive applications you redraw screen every frame (sth like 60 times a second) anyway. And drawing a few more sprites when you're drawing sth anyway is almost free, when you have acceleration. And doing simple animations is much simpler (you just change the proprty you want to with required step per frame, it is refreshed anyway, so no need to mark dirty rectangles, calling .refresh(), etc). Also - perceived latency is low, because from the time you click something to the time screend redraws, there is at most 1/FPS seconds. Most probably less than 20 milliseconds.
dfox 14y ago
Simple solution to this redrawing issue is global flag signifying whether refresh is needed that is cleared in the frame loop after all gui calls. Also complete redraw on every frame is how most game UIs work anyway and it's not significant performance issue today (it was an issue 15 years ago when I wrote several immediate UI libraries for DOS, although performance issue there had more to do with overhead of synchronizing redraws with mouse driver than graphics performance itself). The main problem with this approach is that you essentially end up doing one large busyloop across many irrelevant parts of code. This implementation seems to solve this by blocking at the end of each iteration waiting for any event to occur, but probably still wastes CPU time significantly.

seanmcdirmid 14y ago

For small UIs in games that run at frame rate, the performance is probably competitive to (if not better than) a retained UI. They are probably redrawing their screen on each frame anyways, while retained has its own memory/compute overhead to consider. Now, there is some point where the immediate mode UI becomes uncompetitive with retained; if you have a lot of complex/nested widgets for example, or you care about power consumption for a mostly static UI.

ajuc 14y ago

In games and other interactive applications you redraw screen every frame (sth like 60 times a second) anyway. And drawing a few more sprites when you're drawing sth anyway is almost free, when you have acceleration. And doing simple animations is much simpler (you just change the proprty you want to with required step per frame, it is refreshed anyway, so no need to mark dirty rectangles, calling .refresh(), etc). Also - perceived latency is low, because from the time you click something to the time screend redraws, there is at most 1/FPS seconds. Most probably less than 20 milliseconds.

dfox 14y ago

Simple solution to this redrawing issue is global flag signifying whether refresh is needed that is cleared in the frame loop after all gui calls. Also complete redraw on every frame is how most game UIs work anyway and it's not significant performance issue today (it was an issue 15 years ago when I wrote several immediate UI libraries for DOS, although performance issue there had more to do with overhead of synchronizing redraws with mouse driver than graphics performance itself). The main problem with this approach is that you essentially end up doing one large busyloop across many irrelevant parts of code. This implementation seems to solve this by blocking at the end of each iteration waiting for any event to occur, but probably still wastes CPU time significantly.