[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: Coordination of admins/developers of the game programming library Allegro <alleg-developers@xxxxxxxxxx>
- Subject: Re: [AD] event hooks
- From: Elias Pschernig <elias@xxxxxxxxxx>
- Date: Thu, 14 Dec 2006 11:35:41 +0100
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