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 1117

Summary: [patch] New event for programmatic window size change
Product: SDL Reporter: Martin Decky <martin>
Component: videoAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: HG 2.0   
Hardware: x86_64   
OS: Linux   
Attachments: Proposed patch
Fix local variable initialization and scope

Description Martin Decky 2011-02-12 13:13:59 UTC
Created attachment 567 [details]
Proposed patch

When the SDL_SetWindowSize() is called, it should

(a) Immediately update the window width and height before calling _this->SetWindowSize() (since the new values are required by this function and obviously there is no other way _this->SetWindowSize() can get them).

(b) Generate an event which would notify various parties about the window size change, most notably the renderer.

The latest hg sources fail to do (a), thus the window size does not get altered (e.g. in X11). The window->w and window->h do get updated in SDL_SendWindowEvent() thanks to (b), but then they do not match the physical window size.

Several days ago the SDL sources did implement (a) correctly, but then again the code failed to notify the renderer about the window size change -- in SDL_SendWindowEvent() the SDL_WINDOWEVENT_RESIZED was discarded if the current window->w and window->h equal to data1 and data2 (this was obviously true because of (a)).

In both cases the result was a distorted video output because various data structures contained different window width and height values.

The proposed patch fixes (a) and with respect to (b) it introduces a new event SDL_WINDOWEVENT_SIZE_SET. This event is then used to notify the renderer and other parties about the programmatic window size change.

Note: It would be probably not a good idea to change the behaviour of SDL_WINDOWEVENT_RESIZED and never discard it in SDL_SendWindowEvent(). Some SDL 1.2 applications (e.g. QEMU) call SDL_SetVideoMode() to change the window size, but they do not expect to receive the SDL_WINDOWEVENT_RESIZED event (or SDL_VIDEORESIZE event) as a result. This might cause endless looping, switching to "scaling" mode without any good reason and other troubles.
Comment 1 Sam Lantinga 2011-02-12 17:39:50 UTC
Thank you very much for your patch for SDL 1.3!

Do you give me permission to release your code with SDL 1.3 and future
versions of SDL under both the LGPL and a closed-source commercial
license?
Comment 2 Martin Decky 2011-02-12 17:46:28 UTC
(In reply to comment #1)

> Do you give me permission to release your code with SDL 1.3 and future
> versions of SDL under both the LGPL and a closed-source commercial
> license?

Of course, yes. Permission granted.
Comment 3 Sam Lantinga 2011-02-12 17:52:48 UTC
Thanks! :)
Comment 4 Sam Lantinga 2011-02-12 19:03:12 UTC
I fixed this slightly differently.  I wanted a single event that was always sent when a window was resized, regardless of the reason.
http://hg.libsdl.org/SDL/rev/8e421890cdb8

Can you let me know if this works for you?

Thanks!
Comment 5 Martin Decky 2011-02-13 03:58:49 UTC
Created attachment 569 [details]
Fix local variable initialization and scope

Rationale: The local variable "renderer" needs to be initialized to NULL, otherwise the code in the if (!data) { ... } branch might fail to actually create a renderer (note the second for-loop guarded by (!renderer)).

Secondly, move the "renderer" variable scope into the branch to make sure that the code actually uses data->renderer outside the branch (which holds the only provably correct value in both cases).
Comment 6 Martin Decky 2011-02-13 04:07:11 UTC
Your solution from changeset 8e421890cdb8 works for me perfectly.

BTW: I am sorry again for making such a mess, I just hate this Bugzilla feature of automatically progressing to a next bug after writing a comment. Please go ahead and remove my comment #5 and attachment 569 [details], both are not related to this bug.