This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Sample code (sdl_window_test.c, text/x-csrc, 2013-05-27 05:42:50 +0000, 2647 bytes)
• Sample code (sdl_window_test.c, text/x-csrc, 2013-06-24 17:17:01 +0000, 2767 bytes)

Reported in version: HG 2.0
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2013-05-27 05:42:50 +0000, wrote:

Created attachment 1152
Sample code

Hey,

I have just stumbled upon some hard-to-spot issue (apparently X11 specific), sometimes reproduced with the attached source file (but not always). It can be summarized as follows: Right after a call to SDL_GetWindowSurface is done, any call to SDL_PollEvent (and/or some other event-related function) can mark the window's surface "invalid" due to a resize event, even when you don't expect it.

Here is how I could reproduce this on Ubuntu 12.04 (for x86-64), using "GNOME Classic (No effects)" and "Unity", although it appears to be reproduced more often while "GNOME Classic (No effects)" is being used:

• Create a non-fullscreen window with some dimensions, say 800x600. Furthermore obtain the window's surface using SDL_GetWindowSurface.
• Do some things.
• Resize window to fit the desktop's dimensions and then toggle fullscreen on. Again update the window's surface.
• Do some more things.
• Toggle fullscreen off and then resize the window to different dimensions, like 800x400. As before, update the surface.
• Check the event queue, ignoring any window resize event.
• Try doing even more things, including any update to the window's surface.

The problem is that, at least sometimes, the following things seem to occur:

• When fullscreen is toggled off, the window's dimensions are restored to 800x600 for a short while.
• These change to 800x400 right afterwards.
• An up-to-date window surface is obtained for now.
• A few "delayed" X11 window events arrive, including two resize events: One resize to 800x600 and another one to 800x400.
• Due to the first resize (if not another one), the surface is marked "invalid" (because the window's dimensions have just been set to 800x400 by the program).

I guess that for now, what can be done is telling a programmer using SDL 2.0 the following:

• Use an alternative to SDL_GetWindowSurface (one of the renderers) if possible.
• If the window surface is used (with SDL_GetWindowSurface), always look for a window resize event, even when you don't expect it. When such an event arrives, SDL_GetWindowSurface should be called in order to obtain an up-to-date surface.
• Alternatively, try updating the surface whenever a call to SDL_UpdateWindowSurface or SDL_UpdateWindowSurfaceRects fails.
• It further worths to look for all events, since two consecutive resize events (if not more) may arrive (like desktop -> 800x600 -> 800x400).

On 2013-05-27 08:25:10 +0000, wrote:

The following report (from 2012) may be related, although there are a couple of differences:

• Originally an SDL_Renderer was used, while in the source file I have attached I am simply accessing the window's surface.
• The window was set to resizable, which is not the case in the code I have uploaded.

Link to report: http://forums.libsdl.org/viewtopic.php?t=8426

On 2013-06-24 17:17:01 +0000, wrote:

Created attachment 1195
Sample code

On 2013-06-24 17:19:23 +0000, wrote:

Alright, admittedly there has been a minor mistake in the sample code, which I have just corrected. The bug still applies, though.

More details about the correction to the sample code: SDL_SetWindowSize should not be used for setting the fullscreen window dimensions, even if it appears to work when done before toggling fullscreen on. Rather, SDL_SetWindowDisplayMode should be used (and yeah it works before toggling fullscreen on).

On 2013-07-12 22:15:36 +0000, Ryan C. Gordon wrote:

(Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.)

Tagging a bunch of bugs as target-2.0.0, Priority 2.

This means we're in the final stretch for an official SDL 2.0.0 release! These are the bugs we really want to fix before shipping if humanly possible.

That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.0 release, and generally be organized about what we're aiming to ship.

Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment.

Thanks!
--ryan.