Re: [AD] MSG_IDLE in grabber and menus

[Elias Pschernig <elias@xxxxxxxxxx>]

On Wed, 2004-01-07 at 15:40, Hein Zelle wrote:
> Or is it possible to have a menu open while the rest of the dialog is
> still actively running and being updated?
> 

Well, if you don't use do_dialog, but update_dialog, anything can run
while the menu is running. But I guess, if it is done only for
do_dialog, this works quite well, and you're right - I can't see a
reason why yield_timeslice might hurt - since no (CPU intense or not)
user code can be running anyway.

Hm, there's a lot of possibilities by now:

1 - deprecate do_dialog and leave everything to the user, current code
using do_dialog is out of luck (my patch for grabber went that way..)

2 - scan for d_yield_proc (as Eric suggested)

[3 - add a D_IDLE flag (probably too late at this stage of the GUI)]

4 - call yield_timeslice in do_dialog while a menu is being displayed
(and not in update_dialog)

4b - have a global gui_idle_behavior flag, just like gui_mouse_focus,
which controls if 4 is done or not. Default would be on.

5 - have a global idle callback

If we want current code to use yield_timeslice during menus when and
only when d_yield_proc is used - only solution 2 works.

Personally, I think either way is good (or solution 1) - since I want to
have < 100% CPU usage in Allegro GUI programs, which can't be done with
yield-timeslice, and therefore requires current code to be modified
anyway. (Btw. Angelo told me yesterday in #allegro the reason for the
behavior of yield_timeslice in BeOS/QNX/OSX was that users complained
about the 100% CPU usage of Allegro :)

-- 
Elias Pschernig <elias@xxxxxxxxxx>