Re: [AD] multiple windows

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


On 2006-08-17, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> Here the upper design works good. The lower design works basically the
> same, since merging queues is no problem unlike un-merging (attach all
> three keyboard event sources to the same queue).
> 
> Anyway, I'm fine with the upper way as well, the rate of keyboard events
> probably is low enough that no matter how often you filter the queues
> for events from a specific AL_DISPLAY it won't have a performance
> impact, at least if you use less than 10 windows or so :)

I was going to say it will have no impact whatsoever, but if you have n
threads waiting on n event queues, a keyboard event would inject into n
event queues and wake up n threads at once (and only one thread might
actually care about that).  So that is something in favour of per-window
event sources.

> > > I see. With the global key event source, each window would in its
> > > (platform specific) event loop attach key events to the global keyboard
> > > queue.
> > 
> > What is a "global keyboard queue"?
> > 
> 
> Well, the global AL_KEYBOARD. Was just repeating to myself how it works
> at the driver level - each one attaching to it.

That's just confusing to me, as AL_KEYBOARD is not a queue and does not
behave as one at all.

> > On X, we have a background loop that gets X events from the X server.
> > If the incoming event is a keyboard event we convert that into an
> > AL_KEYBOARD_EVENT and say that it came from the keyboard event source,
> > and inject it into all the event queues which are interested in the
> > keyboard.  The keyboard event source is just a fiction -- event sources
> > only exist so that there is a uniform way to connect various event
> > generating things to event queues.
> > 
> > Other ports are basically the same, except they may have different
> > background threads or multiple background threads, etc.  On all ports we
> > use a separate timer thread to inject events.
> 
> Ah, well, I assume my upper ASCII pictures in the beginning are still
> right though - basically, there is one X11-event handler for each
> window, which filters out keyboard events, and then puts them into the
> (platform independent) global AL_KEYBOARD. (And all the X11-handlers are
> handled from the same background thread.. but we could even use a thread
> for each if we want.)

No, there can only be one X11 handler for the program, unless you open
multiple connections to the X11 server.  The way it works now is:

            X11-events          (incoming events)
                |
             handler            (background thread)
                |
            xkeyboard.c         (massage events, create AL_EVENTs)
            /   |     \
       queue   queue   queue    (these are AL_EVENT_QUEUEs)
        |       |       |
       user    user    user     (userspace)

> > > So yes, it shouldn't make a big difference. My view of an AL_DISPLAY
> > > currently is that of an OS window. And I believe we also will have an
> > > easier time when we can write in the documentation "al_create_display
> > > basically created a window" - compared to "al_create_display creates a
> > > target for graphics operations, which is independent of any input
> > > devices".
> > 
> > Keeping them independent might be conceptually simpler.
> > 
> 
> Well, I don't see that. For someone doing a one-window program, it does
> not matter. And someone who does use multiple OS-windows certainly wants
> to behave them like OS windows.

A single keyboard event source it how it *actually* behaves on X,
although not on Windows.  The X server will not (normally) deliver
keyboard events to your application unless a window owned by your
application is focused, but it doesn't distribute the events to
different queues per window.

> > > > > Well, we have two windows to handle, so each has to do its own
> > > > > XNextEvent. Do we still need a background thread in 4.3 btw?
> > > > 
> > > > Yes.
> > > 
> > > Ok, I also believe it's the simpler design. But my idea was, we could do
> > > without threads if al_get_event() would call a driver method to query
> > > for OS events. It would work on the three platforms in any case. SO,
> > > well, maybe worth considering for a moment, right now it should not be
> > > hard to change it 
> > 
> > I think it will be hard.  If you have multiple threads waiting on
> > multiple Allegro event queues, it could turn really ugly as to who gets
> > to call XNextEvent(), and then having to deliver events to *other* event
> > queues.  Another problem is with events which are not related to X, e.g.
> > timer events.  Now you'd need to merge the events coming from X with the
> > events coming from timers together, which implies keeping a list of pending
> > timer events.
> 
> Well, I do not see the usefulness of timer events, to be honest. But
> it's just that I personally prefer al_get_time() and timeouts, which
> feels more natural to me.

Not if you are writing an event driven program.  Ok, you could use
timeouts but that's a last resort and hard to do right (you'd basically
reimplement the timer background thread).

> Even in the linux console port, it would be ok for users to create an
> AL_DISPLAY first though. We should try to find the common denominator
> here, not look at the possibilities of exotic ports. I consider it
> exotic, since I don't think when 4.4 comes out many will play Allegro
> games in linux console :)

Sure.  Windowless keyboard input was just an example.  Actually, we can
keep the possibility if we allow al_get_keyboard(NULL).


Anyway, if you want per-window keyboard event sources (and other people
seem to agree) I guess it's okay since the problem with keeping track of
N*M event sources is not really bad as in my old design.  It should not
be too hard to add to the current implementation.  I think the
implementation could be quite different from what you think, though.

Would we still have al_install_keyboard()?  It was nice that each event
source type had an al_install_*() equivalent.

How do you want joystick and mouse input devices to behave?  I think
joysticks should NOT be per-window.

Peter





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