1. Use SDL_X11_HAVE_XRENDER to check for RENDER at runtime.
2. Added lots of comments.
3. Added checks and lots of calls to SDL_SetError().
4. Fixed X11_CreateTexture() so that the pixmap and image created
are for the format specified by the user and not the window
format. This is only for the RENDER case.
5. The above change required that functions to convert SDL
pixel format enums to Visuals and XRenderPictFormats be added.
6. Fixed lots of 'style' issues.
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.
