The GUI to end all GUI libraries (Let's Dream!)

[Lutger]

Bill Baxter wrote:
> Julio César Carrascal Urquijo wrote:
>> Lutger wrote:
>>> You can, instead of using a frame-based approach, repaint as needed. 
>>> The lack of state is in the interface, behind the scenes a library 
>>> can do caching. I don't remember the link, but there was some guy who 
>>> rewrote his traditional gui for a cellphone to an imgui one, and 
>>> stated that performance was about the same.
>>>
>>> One benefit though is that in normal gui's, a whole lot a state is 
>>> retained and duplicated between the application and the gui library. 
>>> In complex application, that sucks performance.
>>>
>>
>> All the implementations I've seen use real-time redrawing which is 
>> obviously overkill for this type of application. But you are right, it 
>> is certainly possible.
> 
> Casey does mention it as a drawback of immediate mode GUI in the video. 
>  If you want lazy updates, the burden of implementing it is on the 
> application as opposed to retained mode GUIs where the toolkit can 
> handle it for you.  But even then a lot of GUI systems have some sort of 
> update() or refresh() call that you have to remember to call to tell it 
> that something changed.  So it's not that different I don't think.
> 
> --bb

In my toy imgui, I only update when there are events, and even then only 
when some state has changed the thing need to be rendered again. This is 
all behind the scenes though, so the user doesn't have to do anything. 
This is lazy enough in practice, I guess it's a trade between executing 
the gui logic on every event in the imgui case and retaining state in 
rmgui.