Event-driven apps in SDL Was: iOS System Callback

Sorry about the sparse source info, haven’t received the digest yet.

On: Sun Apr 1 18:07:47 PDT 2012

We are confronted with a fundamental choice of approach:

  1. SDL_main - app provides its own run loop in the single
    SDL_main function. (existing behavior)

  2. event-driven - app provides only event handlers, must
    stuff its own event queue with timer events to continue
    animation, etc. (more compatible)

Not precisely a necessary choice for the library. The event queue that
the original approach uses ultimately has to get it’s events from
somewhere, and an event-driven system is just as reasonable of a
source as anything else.

That having been said, I DID consider suggesting that the event queue
be separated out into a separate set of structures & functions, so
that developers can have their own event queues for e.g. pipelining.
If the relevant functions were thread-safe, then it could even be used
as a decent inter-thread communications system (each thread is
allocated a queue by the code that creates that thread).

So I propose that we should allow apps to be written for
either model, with a big disclaimer about “Using SDL_main()
on OSX, iOS and Android is not recommended and may be
buggy”.

We could do this by providing two versions of the SDLmain
code module to use in your app, one sets up the event-driven
model (not linking to SDL_main in the app but rather to a set
of event handler functions) where as the other provides the
existing functionality of simply invoking SDL_main in the app.

I don’t think that having two versions of SDLmain is a good first choice.

I should note that if we support the option of event-driven apps,
then SDL could additionally support web browser plugin APIs
(Netscape Plugin API, Google NativeClient/Pepper Plugin API,
Microsoft ActiveX controls), which I think a lot of people would
be interested in.

That would certainly be very nice.

On: Sun Apr 1 20:51:09 PDT 2012

Jared wrote:

Fortunately, my proposed variant doesn’t have this problem. No mode
switching, no magically knowing which generic events are hooked by
callback & which aren’t, just a simple add-in system where the
callback can effectively say “pretend I don’t exist”. It provides an
implementation route for Eric’s future-proofing, without requiring
SDL’s maintainers to keep track of when a particular event was moved
to the callback system.

In all cases of my proposed variant, returning -1 if the callback
doesn’t recognize either the SDL_callbackstage value or the event type
is correct, because it basically means “do the default”. Thus, if the
callback either doesn’t know about or care about some particular
SDL_callbackstage or event (or combination of the two) then it simply
does nothing other than return -1, and (one way or another) SDL will
do the default action.

That’s a good idea but it can add a lot of overhead, especially in the
problem were trying to solve which is time critical (the OS will actually
attempt to halt you if you take to long to do what you are doing.)

That’s obnoxious of them. Understandable, though (consider: with PWM
events, the hardware itself doesn’t have much choice in the matter).

Would a simpler solution be use Eric’s version, add a boolean return,

I still suggest the use of an explicit int, since the idea of
returning -1 is that SDL should pretend that no callback was
registered. Still, if we feel confident that there will never be a
change in behavior when a function is registered, then a boolean is
perfectly fine (technically, isn’t SDL’s boolean type a typedef of
int?).

if you return TRUE, you’ve handled the event, if you return FALSE,
drop the event on the queue to later be picked up by an event poll?
That solves the problem in the same way without a lot of overhead,
and future proofs an iOS code (just return TRUE for all the iOS events,
but FALSE for everything else.)

This is basically the same solution you’ve proposed, but without the
various before/after stages. I’m not sure this would ever be useful, but
I like the direction. Regardless, this would solve (so far) all the major
problems.

You forgot one bit: suspending/resuming SDL. I’m not all that
convinced that all of the invocations are needed either, but I do
think that at least 2 are needed: one before suspend/resume, another
after. The reason why is that if you’re suspending or resuming SDL,
then you likely want to do the same for some other libraries that
you’re running as well. If all of them support this sort of interface
then you just need to locate the callback in the right place for each
event, but that isn’t likely to happen. Thus, you need a 'hook point’
for both libraries that need to be suspended before/resumed after SDL,
and for libraries that need the opposite.

Still, two callback invocations should presumably be enough for that.

Controlling the return of the event handler might be a nice idea for
the second callback, but I’d be lying if I said I trusted all event
systems to have nice, compliant return values (or even return values
at all), so it’s very much an “in your dreams” sort of thing.> From: Forest Hale havoc at ghdigital.com

Subject: [SDL] Event-driven apps in SDL Was: iOS System Callback
From: Brian Barnes ggadwa at charter.net
Subject: [SDL] iOS System Callback