This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Little code which show the bug. Press [Return] to resize and see resize events. (testResize.c, application/octet-stream, 2012-07-19 03:28:37 +0000, 1239 bytes)
• This fixes the issue where VIDEORESIZE is sent when calling SDL_SetVideoMode() (noresize.patch, text/plain, 2012-07-25 12:04:08 +0000, 440 bytes)
• This removes resize events when the window didn't change size (remove_spurious_resize.patch, text/plain, 2012-07-25 12:07:45 +0000, 1390 bytes)

Reported in version: 1.2.15
Reported for operating system, platform: Windows (All), All

Comments on the original bug report:

On 2012-07-19 03:28:37 +0000, Thibault D wrote:

Created attachment 905
Little code which show the bug. Press [Return] to resize and see resize events.

Each call to SetVideoMode, done without VIDEORESIZE event, and which effectively changes the window size generates an SDL_VIDEORESIZE event.

From Sam Lantiga:
"The intent is that you only get the resize event if the window size is changed outside of SDL_SetVideoMode(). If it's not working that way, it's a bug."

It was not present in 1.2.13 neither in 1.2.14 on this system.
This occurs both with the directx and windib drivers on Windows 7 64bit.

Note: At the very first call, there will always be an VIDEORESIZE event.

Note (Debug): I wrote "effectively change the window size" because in fullscreen, only few resolutions are supported and SDL will give you the closest to the one you asked. So if you are in 640x480 (fullscreen or not) and you ask a 639x480 FULLSCREEN, there won't be any resize event because SDL will have give you an 640x480 which means, no change.

On 2012-07-25 09:50:40 +0000, Patrick Baggett wrote:

In SDL_video.c (ln 681) I see:

---

if ( mode ) { /* Prevent resize events from mode change /
/ But not on OS/2 */
#ifndef OS2
SDL_PrivateResize(mode->w, mode->h);
#endif

---

So, prevent resize events except on OS/2? It seems like the #ifndef should be
#ifdef, i.e. ONLY on OS/2 should the resize happen, otherwise it is prevented...

On 2012-07-25 12:04:08 +0000, Patrick Baggett wrote:

Created attachment 912
This fixes the issue where VIDEORESIZE is sent when calling SDL_SetVideoMode()

[1/2] This changes the #ifndef to #ifdef. The comment implies that a resize shouldn't happen unless running on OS/2. The code however did the opposite: resize is sent on all platforms except for OS/2. This fixes it so the behavior matches the comment.

On 2012-07-25 12:07:45 +0000, Patrick Baggett wrote:

Created attachment 913
This removes resize events when the window didn't change size

[2/2] This patch fixes Win32 behavior I noticed when switching focus -- sometimes a VIDEORESIZE message is sent for no apparent reason. The Win32 event that generated it is WM_WINDOWPOSCHANGED, which can mean either the position OR the size changed. However, the VIDEORESIZE event is sent regardless of which occured. This only sends a resize if the size of the window did in fact change.

On 2015-08-25 09:38:23 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email (icculus@icculus.org) and we'll try to find some way to help you out of your situation.

Thank you,
--ryan.