Re: [AD] event hooks

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Thu, 2006-12-14 at 12:11 +1100, Peter Wang wrote:
> On 2006-12-13, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> > On Thu, 2006-12-14 at 01:13 +1100, Peter Wang wrote:
> > > 
> > > A problem is that a single event may be delivered to multiple event
> > > queues, a callback might be called multiple times for the same event.
> > 
> > I see. Probably could add a flag which gets cleared.
> 
> That will preclude an implementation of events where AL_EVENTs are
> delivered to event queues by copying their contents, rather than passing
> a pointer.  The current implementation uses the latter, but I think it's
> a mistake.
> 
> Ok, with copying, we could still share a flag, but that's too
> complicated.

Well, I don't have a clear picture yet of a scenario where an event is
delivered to multiple queues. I guess we should have a tests folder like
in your A5, which then would have one multi-queue test.

Another thing that might be possible, with a different kind of events
hook, would be a thread-less Allegro. So al_get_next_event,
al_peek_next_event and so on could call an "al_poll", which then calls
whatever is now called by the background thread. Can't see an advantage
though, unless maybe for a DOS driver attempt.

> 
> I see you've called it al_acknowledge_resize() in SVN, which I quite
> like.  Or al_ack_resize(AL_DISPLAY *display); ?

Yeah, makes it easier to keep 80 char lines I guess.

> > Actually, I just had another thought, this function could again be
> > called automatically, but not from the events handling, but from
> > al_flip() this time.
> 
> I'm not sure.  Part of the acknowledgement is not only that Allegro gets
> a chance to fix stuff up, but the user gets an opportunity as well.
> Do you consider this problematic?
> 
>     al_wait_for_event(&ev);
>     switch (ev.type) {
> 
> 	case AL_EVENT_DISPLAY_EXPOSE:
> 	    ...
> 	    al_flip();	    // may cause a resize acknowledgement
> 	    break;
> 
> 	case AL_EVENT_DISPLAY_RESIZE:
> 	    ...
> 	    al_flip();
> 	    break;
> 	...
>     }
> 

Yeah, in fact, it could be an al_flip somewhere in the graphics code of
the user program acknowledging the resize/expose then as well. Not sure
how much of a problem it would be in practice though. If it's a program
updating the complete window contents each frame, it shouldn't matter at
all - e.g. in my exnewapi.

The question is mainly, do we want a solution where if the user forgets
the acknowledge calls, it won't work at all, or one which is a bit less
clean (just do it in al_flip).

-- 
Elias Pschernig





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/