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

["olivier.landemarre@utbm.fr" <Olivier.Landemarre@utbm.fr>]

Selon 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.

I dislike too! But for compatibility I think there is no way to change it, this
is quite more complex in other AES, even if a MU_MESSAG and MU_TIMER is avaible
at the same time, the MU_TIMER will be reset, it should not but it is, I have
discover this because with MyAeS some time I lost some message in my own
softwares I find a bug in my library to do my software, but it alway's work with
other AES! I have decide to do the same in MyAeS. Most of time TIMER is use by
GEM application to have a timeout to not stay in AES, value of timer is not
important, if you wan't add new feature you have probably to add something like
a new evnt_multi() flag like MU_TIMER_RESIDENT, with this no conflict possible
with old application, and the gem API is not change only this flag is add,
perhaps MU_TIMER_RESIDENT should be put with MU_TIMER in same time
(MU_TIMER_RESIDENT|MU_TIMER) for a sort of backward compatibility for older AES.

Olivier

>
>
>  Best Regards
> Odd Skancke
>
>
>
>
>
>


--