Re: [AD] Proposal for an input model

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> For platforms with polled input, like X-windows and other message
> based systems, the use of asynchronous framework will complicate
> things.

Note that I've never claimed model 3 is as simple as model 2, it has
actually roughly the same complexity as that of model 1. Now the complexity
of model 1 has already been successfully mastered for Allegro 4.0, including
for X11 with _bg_man_sigalrm or _bg_man_pthreads, so I assume converting
model 1 into model 3 won't be a big problem.

I'm not against putting Allegro on the diet, but I'd rather put into
separate modules things that don't belong to the core library than remove
core features of Allegro 4.0, because it obviously means moving the
complexity from the library to the user.

> But systems with polling will call these callbacks from al_poll_keyboard.
>
> void al_set_keyboard_callback (void (*cb) (something));
>
> 'void cb (something)' will be called asynchronously when keyboard
> state changes, or when this change is detected in al_poll_keyboard.

Do you mean only when the *user* calls al_poll_keyboard() ? If so, that's
not exactly what I'd call asynchronous input. Otherwise, it's the job of the
asynchronous framework (i.e the input thread) to call the callbacks, but it
could of course instruct al_poll_keyboard() to do it on its behalf, and only
call al_poll_keyboard() in the thread function.

> BTW, IMHO, it is necessary to poll explicitely, implicit polling in
> every input function may give bad performance on some systems.

Of course.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx