Re: [MiNT] [XAAES] Does not generate MU_TIMER events when asked

[Odd Skancke <ozk@atari.org>]

tor, 07,.07.2005 kl. 13.56 +0200, skrev Odd Skancke:
> tor, 07,.07.2005 kl. 13.29 +0200, skrev Patrice Mandin:
> > Hello,
> > 
> > I have a big problem with Xaaes when running SDL programs:
> > 
> > I use MU_TIMER to avoid waiting for AES events for too long, however
> > Xaaes never generates MU_TIMER events when I ask him to do so. All my
> > programs get stuck in the loop that calls AES event_multi(), waiting for
> > a MU_TIMER event that never comes.
> 
>  Just ran the testprogram, and can confirm that this is a big problem
> yes. I will see if I can figure it out as soon as possible.

 Ok, I know now what is 'wrong' .. 

 In XaAES timer events are cancelled when any other AES events happens.
The reason for this is that there is no mechanism to tell the AES that
one wants to wait for a 'pending timeout', set by an earlier evnt_multi
(). So, the problem seen with the test application is that MU_Mx events
happens before the set timeout fires, and the timeout is cancelled upon
delivering events to the client and reset again on the next evnt_multi
(). I'm not sure how this is handled in other AES's, but I can imagine
something like this;

 If a previous MU_TIMER has not yet timed out, do not use the value
passed by evnt_multi(), but let the pending timeout continue. This means
MU_TIMER requests are ignored by evnt_multi() (and perhaps evnt_timer())
if there is already a timeout pending.

 Summary;

 XaAES always resets a fresh timeout on every evnt_multi(), meaning that
if one also MU_Mx to look for mousemovements, a timeout value of 10, for
example, will never happen as long as the user moves the mouse.

 Other AES's ignores consecutive MU_TIMER settings until the first one
actually has happened. I think this basically means one cannot change or
cancel a timeout already set.


 I dont like the 'other AES' method, and am fishing for suggestions
here.



 Best Regards
Odd Skancke