Sat, 07 Oct 2017 12:00:04 +0200atari:gem: Handle padding redraw when moving window behind other windows SDL-1.2
Patrice Mandin <patmandin@gmail.com> [Sat, 07 Oct 2017 12:00:04 +0200] rev 11576
atari:gem: Handle padding redraw when moving window behind other windows

Fri, 06 Oct 2017 21:43:59 -0700Fixed restoring window size when coming out of fullscreen desktop mode.
Sam Lantinga <slouken@libsdl.org> [Fri, 06 Oct 2017 21:43:59 -0700] rev 11575
Fixed restoring window size when coming out of fullscreen desktop mode.
Use the style of the window as it will be, not as it currently is at the
time of the AdjustWindowRect call.

Fri, 06 Oct 2017 16:50:24 -0700Fixed bug 3857 - SDL_ConvertPixels misses YUV conversions
Sam Lantinga <slouken@libsdl.org> [Fri, 06 Oct 2017 16:50:24 -0700] rev 11574
Fixed bug 3857 - SDL_ConvertPixels misses YUV conversions

Sylvain

Few issues with YUV on SDL2 when using odd dimensions, and missing conversions from/back to YUV formats.

1) The big part is that SDL_ConvertPixels() does not convert to/from YUV in most cases. This now works with any format and also with odd dimensions,
by adding two internal functions SDL_ConvertPixels_YUV_to_ARGB8888 and SDL_ConvertPixels_ARGB8888_to_YUV (could it be XRGB888 ?).
The target format is hard coded to ARGB888 (which is the default in the internal of the software renderer).
In case of different YUV conversion, it will do an intermediate conversion to a ARGB8888 buffer.

SDL_ConvertPixels_YUV_to_ARGB8888 is somehow redundant with all the "Color*Dither*Mod*".
But it allows some completeness of SDL_ConvertPixels to handle all YUV format.
It also works with odd dimensions.

Moreover, I did some benchmark(SDL_ConvertPixel vs Color32DitherYV12Mod1X and Color32DitherYUY2Mod1X).
gcc-6.3 and clang-4.0. gcc performs better than clang. And, with gcc, SDL_ConvertPixels() performs better (20%) than the two C function Color32Dither*().
For instance, to convert 10 times a 3888x2592 image, it takes ~195 ms with SDL_ConvertPixels and ~235 ms with Color32Dither*().
Especially because of gcc vectorize feature that optimises all conversion loops (-ftree-loop-vectorize).

Nb: I put no image pitch for the YUV buffers. because it complexify a little bit the code and the API :
There would be some ambiguity when setting the pitch exactly to image width:
would it a be pitch of image width (for luma and chroma). or just contiguous data ? (could set pitch=0 for the later).


2) Small issues with odd dimensions:
If width "w" is odd, luma plane width is still "w" whereas chroma planes will be "(w + 1)/2". Almost the same for odd h.
Solution is to strategically substitute "w" by "(w+1)/2" at the good places ...

- In the repository, SDL_ConvertPixels() handles YUV only if yuv source format is exactly the same as YUV destination format.
It basically does a memcpy of pixels, but it's done incorrectly when width or height is odd (wrong size of chroma planes). This is fixed.

- SDL Renderers don't support odd width/height for YUV textures.
This is fixed for software, opengl, opengles2. (opengles 1 does not support it and fallback to software rendering).
This is *not* fixed for D3D and D3D11 ... (and others, psp ?)
Only *two* Dither function are fixed ... not sure if others are really used.

- This is not possible to create a NV12/NV12 texture with the software renderer, whereas other renderers allow it.
This is fixed, by using SDL_ConvertPixels underneath.

- It was not possible to SDL_UpdateTexture() of format NV12/NV21 with the software renderer. this is fixed.

Here's also two testcases:
- that do all combination of conversion.
- to test partial UpdateTexture

Fri, 06 Oct 2017 16:42:43 -0700Fixed bug 3862 - Install is broken when adding SDL2 to an existing CMake project
Sam Lantinga <slouken@libsdl.org> [Fri, 06 Oct 2017 16:42:43 -0700] rev 11573
Fixed bug 3862 - Install is broken when adding SDL2 to an existing CMake project

Steve Robinson

In my existing CMake project, I use add_subdirectory to add the source for SDL2. This worked fine in 2.0.5, but now in 2.0.6 when I build the INSTALL CMake target, I get this error:

file INSTALL cannot find "D:/path/to/SDL2Config.cmake".
Call Stack (most recent call first):
3rdparty/SDL2/cmake_install.cmake:32 (include)
3rdparty/cmake_install.cmake:36 (include)
cmake_install.cmake:32 (include)

To fix this, I changed line 1770 from this:
${CMAKE_SOURCE_DIR}/SDL2Config.cmake

To this:
${CMAKE_CURRENT_SOURCE_DIR}/SDL2Config.cmake

Fri, 06 Oct 2017 16:17:50 -0700Fixed potential overflow in surface allocation (thanks Yves!)
Sam Lantinga <slouken@libsdl.org> [Fri, 06 Oct 2017 16:17:50 -0700] rev 11572
Fixed potential overflow in surface allocation (thanks Yves!)

Sat, 07 Oct 2017 00:40:47 +0200atari:gem: Remove duplicated debug code SDL-1.2
Patrice Mandin <patmandin@gmail.com> [Sat, 07 Oct 2017 00:40:47 +0200] rev 11571
atari:gem: Remove duplicated debug code

Sat, 07 Oct 2017 00:38:38 +0200atari:gem: simplify refresh_window routine by merging icon and normal drawing states SDL-1.2
Patrice Mandin <patmandin@gmail.com> [Sat, 07 Oct 2017 00:38:38 +0200] rev 11570
atari:gem: simplify refresh_window routine by merging icon and normal drawing states

Sat, 07 Oct 2017 00:30:13 +0200atari:gem: Add GEM_ClearRectXYWH to clear rectangle with x,y,w*h coordinates. Rename pxy array to rect to distinguish pxy (x1,y1,x2,y2) from rect (x,y,w*h) coords. SDL-1.2
Patrice Mandin <patmandin@gmail.com> [Sat, 07 Oct 2017 00:30:13 +0200] rev 11569
atari:gem: Add GEM_ClearRectXYWH to clear rectangle with x,y,w*h coordinates. Rename pxy array to rect to distinguish pxy (x1,y1,x2,y2) from rect (x,y,w*h) coords.

Sat, 07 Oct 2017 00:10:57 +0200atari:gem: Store iconified state so we do not have to query system on each frame. SDL-1.2
Patrice Mandin <patmandin@gmail.com> [Sat, 07 Oct 2017 00:10:57 +0200] rev 11568
atari:gem: Store iconified state so we do not have to query system on each frame.

Thu, 05 Oct 2017 09:37:28 -0700Fixed bug 3854 - arguments to dbus_type_is_basic() were incorrect
Sam Lantinga <slouken@libsdl.org> [Thu, 05 Oct 2017 09:37:28 -0700] rev 11567
Fixed bug 3854 - arguments to dbus_type_is_basic() were incorrect

Aaron

As of 2.0.6, all of my games are failing with the following error:

process 31778: arguments to dbus_type_is_basic() were incorrect, assertion "dbus_type_is_valid (typecode) || typecode == DBUS_TYPE_INVALID" failed in file dbus-signature.c line 322.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace

(patch by Ozkan Sezer)