Don't crash if someone tries to delete a context after we've unloaded the library. In this case it's SDL_compat that doesn't know SDL_VideoQuit() has been called. Hmm...
In function GLES_RenderCopy() in SDL_renderer_gles.c:819 there is one memcpy()
that can be avoided if we're updating whole texture.
Because of that the SDL 1.3 in compatibility mode is working even slower than
software rendering in SDL 1.2.
Unfortunately, this doesn't work. I also noticed that maximizing doesn't work as well. Also xprop hangs when trying to list properties of SDL windows.... ???
If a non-console Windows SDL program has a non-quoted 0th argument followed
optionally by more non-quoted arguments and then by an empty quoted argument,
it will crash (attempts to dereference a NULL pointer).
In other words, something like this:
test.exe [non-quoted args] "" [...]
The fix is a one-liner in ParseCommandLine() of
src/main/win32/SDL_win32_main.c.
You can test this with any non-console SDL program on windows like this:
1) Open a console (cmd.exe)
2) Launch the program in one of the following ways:
program ""
program arg1 ""
program arg1 "" arg3
These will not cause a crash:
"program" [...]
program "arg1" ""
When a Windows program is launched from Explorer, its 0th argument seems to
always be quoted, so it won't be a problem in that case.
I've tested this on Windows XP SP3 and Windows 7.
As far as I know there isn't any real way to tell when the clipboard contents have changed without polling them, so I didn't implement the clipboard update event on X11.
A complete clipboard implementation would support multiple formats that could be queried at runtime, events for when the clipboard contents changed, support for HTML, images, etc. We're not going that crazy, at least for now. :)
Fixed a bug where only mouse wheel up was sent on Mac OS X
Fixed a bug where mouse window focus was getting hosed by the fullscreen mouse code on Mac OS X
