It’s deliberate, and commented (to a degree), but precisely what the
underlying issue is I don’t know (the comment goes on to talk about
“important to get certain elements of Game Center’s
GKLeaderboardViewController to respond to touch input” which sounds pretty
obscure). But my workaround is effective and my intention is always to
limit the rate at which I call SDL_PumpEvents() from now on.
I haven’t noticed this myself, but my suspicion is that it caused by
the way SDL does its event loop. The problem is that SDL tries to take
control of the event loop so you can write a top-to-bottom procedural
poll-driven “int main()”. This worked on the old platforms (e.g.
Windows, traditional Unix, etc.), but has become problematic on the
newer platforms (e.g. OSX, iOS, Android, Emscripten).
In these latter platforms, the OS wants to control the event loop and
you are not supposed to ever block it. So the typical SDL “int main()”
pattern would block these loops and not work. To preserve SDL’s
paradigm, hoop jumping acrobatics are done. Unfortunately, all of
these workarounds have various problems.
I know from personal experience doing a lot of Cocoa work, that not
using Apple’s normal event loop can break certain Apple APIs and
frameworks, because their own code depends on that behavior.
GameCenter was at one time (and still may be) one of those frameworks.
We’ve also seen menu and window focus problems with SDL on Mac due to
not using the standard event loop. As for the lag, I don’t know the
reason, but I could speculate that trying to query for input events at
random times, not tied to Apple’s standard event model may be a
reason…consider maybe the events are designed to come through at a
certain time into the Cocoa framework which was coordinated with the
rest of the Cocoa event loop. With SDL, since we are not synchronized
to that event loop, our queries might be just a little too early, and
we have to wait another frame for them to appear.
On Android, the problem is worse because the only workaround was to
put SDL on a background thread. If you only stick to only SDL APIs and
OpenGL, you won’t notice anything, but the moment you need to interact
with anything on the UI thread (e.g. In App Billing modules, Facebook
plugin, etc.), you are in for a world of hurt. Also, the whole Android
life-cycle is extra painful with SDL because there are a lot of sync
point issues with getting SDL to do the right thing immediately on a
different thread than the main Android app.
On Emscripten, SDL had to give up because there is no mechanism to
control the event loop in the web brower, PERIOD. And the web doesn’t
allow threads (and I don’t think web workers are sufficient for SDL’s
case). So for Emscipten, SDL introduced a new extension API that calls
back on a new frame, and you are expected to run through (just once)
your main event loop through that.
My belief is that the new SDL API for Emscpiten is the better way to
deal with the event loop moving forward. Most new platforms are moving
to the same event-driven OS loop control, for various reasons…but
battery life has become a strong motivator for vendors for this in
recent years. Also, most new platforms provide high performance
callbacks on frame draws, which SDL could utilized. And most
importantly for cross-platform, I think it is always possible to turn
a procedural top-to-bottom event loop into something that resembles
event driven, but it is not always possible to (perfectly) convert a
native event-driven into a procedural top-to-bottom-loop (as we’ve
seen with Emscripten, Android, and Apple).
I talked about cross-platform event loop issues in my talk about the
cross-platform native GUI framework, IUP. And I walk through how to
convert the poll-driven traditional loops used by Unix and Windows in
IUP into an event-driven model, to re-unify with the new Mac, iOS,
Android, and Emscripten backends I’ve been developing which all are
natively event-driven.
A digression, one of my (very) long term goals is to make SDL work with IUP.
-Eric
