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.
Fixes involved:
1. Fix handling of alpha channel when SDL_BLENDMODE_NONE is set.
2. Make xrendercolor use floating-point values for color channels and then convert to 16 bit ints.
3. Fix handling of visuals in SDL_x11modes.c so that a 32 bit ARGB visual is used.
4. Fix the background pixel value in SDL_x11window.c so that the window background has an alpha value of 0xFF and not 0.
