Wed, 24 May 2017 13:28:13 -0400coreaudio: we don't need to track number of allocated audio buffers anymore.
Ryan C. Gordon [Wed, 24 May 2017 13:28:13 -0400] rev 11027
coreaudio: we don't need to track number of allocated audio buffers anymore.

CoreAudio takes care of iterating through the buffers and freeing them now,
so we don't have to manage this ourselves.

Wed, 24 May 2017 13:25:31 -0400coreaudio: Better handling of audio buffer queue management.
Ryan C. Gordon [Wed, 24 May 2017 13:25:31 -0400] rev 11026
coreaudio: Better handling of audio buffer queue management.

We don't fill buffers just to throw them away during shutdown now, we let the
AudioQueue free its own buffers during disposal (which fixes possible warnings
getting printed to stderr by CoreAudio), and we stop the queue after running
any queued audio during shutdown, which prevents dropping the end of the
audio playback if you opened the device with an enormous sample buffer.

Fixes Bugzilla #3555.

Wed, 24 May 2017 14:04:39 +0100Emscripten: Prevent default on arrow keys
Charlie Birks [Wed, 24 May 2017 14:04:39 +0100] rev 11025
Emscripten: Prevent default on arrow keys

Wed, 24 May 2017 14:04:25 +0100Emscripten: fixed incorrect conversion of touch motion events to mouse motion events
Patrick Monaghan [Wed, 24 May 2017 14:04:25 +0100] rev 11024
Emscripten: fixed incorrect conversion of touch motion events to mouse motion events

Wed, 24 May 2017 01:28:03 -0400coreaudio: looks like we need more like a 10ms buffer minimum, not 50ms.
Ryan C. Gordon [Wed, 24 May 2017 01:28:03 -0400] rev 11023
coreaudio: looks like we need more like a 10ms buffer minimum, not 50ms.

Wed, 24 May 2017 00:12:22 -0400coreaudio: dynamically allocate AudioQueueBuffers.
Ryan C. Gordon [Wed, 24 May 2017 00:12:22 -0400] rev 11022
coreaudio: dynamically allocate AudioQueueBuffers.

We need more than two buffers to flip between if they are small, or CoreAudio
won't make any sound; apparently it needs X milliseconds of audio queued when
it needs to play more or it drops any queued buffers. We are currently
guessing 50 milliseconds as a minimum, but there's probably a more proper
way to get the minimum time period from the system.

Fixes Bugzilla #3656.

Sat, 20 May 2017 23:30:47 +0200Removed unnecessary call to free() in testoverlay2 program.
Philipp Wiesemann [Sat, 20 May 2017 23:30:47 +0200] rev 11021
Removed unnecessary call to free() in testoverlay2 program.

Sat, 20 May 2017 23:30:32 +0200Removed unused signal includes and handler in test programs.
Philipp Wiesemann [Sat, 20 May 2017 23:30:32 +0200] rev 11020
Removed unused signal includes and handler in test programs.

Fri, 19 May 2017 23:30:59 +0200Removed redundant mouse clean up on quit for some platforms.
Philipp Wiesemann [Fri, 19 May 2017 23:30:59 +0200] rev 11019
Removed redundant mouse clean up on quit for some platforms.

SDL_MouseQuit() already frees cursors and sets fields to NULL.

Fri, 19 May 2017 15:06:05 -0400android: add screenSize to AndroidManifest's configChanges (thanks, Daniel!).
Ryan C. Gordon [Fri, 19 May 2017 15:06:05 -0400] rev 11018
android: add screenSize to AndroidManifest's configChanges (thanks, Daniel!).

Fixes Bugzilla #3448.

"Starting with Android API 13, another configuration change must be declared
to be handled by the app if it is desired to not let the system handle
rotation itself:

https://developer.android.com/guide/topics/resources/runtime-changes.html#HandlingTheChange

This will have effect if either a developer or SDL per default will set target
API > 12. Currently it is set to 12, but this might change in the future, like
when applying this patch: https://bugzilla.libsdl.org/show_bug.cgi?id=3445

The effect of not having this change applied is that the SDL app is destroyed
upon rotation. Even when the manifest has an additional entry to e.g. always
stay in landscape mode, the onDestroy() call will happen on devices that are
portrait per default, when switching off screen due to power save. The device
will then (at least try to) rotate into portrait to show the portrait screen
lock after resume.

I believe it is safe to apply this patch even with target API still set to 12,
the additional parameter is simply ignored."