We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1544 - "Manually" changing the size with SetVideoMode triggers VIDEORESIZE
Summary: "Manually" changing the size with SetVideoMode triggers VIDEORESIZE
Status: RESOLVED ENDOFLIFE
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 1.2.15
Hardware: All Windows (All)
: P2 normal
Assignee: Patrick Baggett
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-19 03:28 UTC by Thibault D
Modified: 2015-08-25 09:38 UTC (History)
1 user (show)

See Also:

Attachments
Little code which show the bug. Press [Return] to resize and see resize events. (1.21 KB, application/octet-stream)
2012-07-19 03:28 UTC, Thibault D 		Details
This fixes the issue where VIDEORESIZE is sent when calling SDL_SetVideoMode() (440 bytes, patch)
2012-07-25 12:04 UTC, Patrick Baggett 		Details | Diff
This removes resize events when the window didn't change size (1.36 KB, patch)
2012-07-25 12:07 UTC, Patrick Baggett 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thibault D 2012-07-19 03:28:37 UTC 
Created attachment 905 [details]
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.
Comment 1 Patrick Baggett 2012-07-25 09:50:40 UTC 
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...
Comment 2 Patrick Baggett 2012-07-25 12:04:08 UTC 
Created attachment 912 [details]
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.
Comment 3 Patrick Baggett 2012-07-25 12:07:45 UTC 
Created attachment 913 [details]
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.
Comment 4 Ryan C. Gordon 2015-08-25 09:38:23 UTC 
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.