Hybrid GUI beta release - an IM+RM GUI toolkit for games, multimedia, etc

[Tom S]

Mike wrote:
> Looks great and very impressive. However, calc.exe skyrocketed to 25% 
> CPU here (this is a fairly decent gaming machine, it even runs Crysis 
> nicely), and half a core just for such a little thing seems a bit 
> surprising. What values are usually expected?

Well, normal GUIs idle most of the time, only doing a redraw and a state 
update when it's more or less necessary. Hybrid draws and updates its 
stuff in a loop, thus without any sleeping or yielding, it will use one 
core completely. When such a GUI is used within a game or some 
application which has to redraw its display continuously, this is not an 
issue.

Main page of the wiki says: "Hybrid does not currently support any form 
of lazy updating or rendering, thus may not be suited for applications 
that don't redraw and update their state every frame."

... and the Overview section states it again: "The most serious drawback 
of Hybrid is that it's tricky to do lazy state updates with it. In order 
for it to have an immediate-mode API, some code has to be executed once 
per frame (once per mouse move / keyboard press in the best case). So 
far, lazy updating remains a distant option and not a top priority, but 
to some extent, it should be possible in the long run."

If your app has a mostly static GUI and should not use the CPU, Hybrid 
may not be a good option for you. But even adding a simple 
Thread.yield() at the end of the loop will make it go nicely with other 
apps. AFAIK, most desktop operating systems increase the thread priority 
of the top-most window's process, so switching to another app that needs 
the CPU power will get it the CPU cycles. Decreasing the thread priority 
is also an option.

Hope this makes it a bit clearer

-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode