The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

SDL Forum Index
SDL
Simple Directmedia Layer Forums
resize
john skaller
Guest
Post Posted: Sat Aug 03, 2013 2:08 pm
Can anyone explain the difference between:

SDL_WINDOWEVENT_RESIZED, /**< Window has been resized to data1xdata2 */
SDL_WINDOWEVENT_SIZE_CHANGED, /**< The window size has changed, either as a result of an API call or through the system or user changing the window size. */

--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
David Gow
Guest
Post Posted: Sat Aug 03, 2013 2:13 pm
As I understand it, SDL_WINDOWEVENT_SIZE_CHANGED is sent when you
explicitly resize the window using SDL_SetWindowSize() or similar
(changing fullscreen resolutions, for example), whereas
SDL_WINDOWEVENT_RESIZED is sent when the window is resized by something
other than a direct API call. It's been a while since I looked at that
code though, so I could be wrong, though.

In any case, you shouldn't have any problems just handling both of them.

-- David

On 03/08/13 22:07, john skaller wrote:
Quote:
Can anyone explain the difference between:

SDL_WINDOWEVENT_RESIZED, /**< Window has been resized to data1xdata2 */
SDL_WINDOWEVENT_SIZE_CHANGED, /**< The window size has changed, either as a result of an API call or through the system or user changing the window size. */

--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
john skaller
Guest
Post Posted: Sat Aug 03, 2013 11:59 pm
On 04/08/2013, at 12:13 AM, David Gow wrote:

Quote:
As I understand it, SDL_WINDOWEVENT_SIZE_CHANGED is sent when you explicitly resize the window using SDL_SetWindowSize() or similar (changing fullscreen resolutions, for example), whereas SDL_WINDOWEVENT_RESIZED is sent when the window is resized by something other than a direct API call. It's been a while since I looked at that code though, so I could be wrong, though.

In any case, you shouldn't have any problems just handling both of them.


This makes sense, but I would like an authoritative response.

When I drag the bottom right corner with the mouse on OSX,
which is the normal way to resize a window on OSX,
I get *both* events.

I guess one means "the user is trying to resize the window" and
the other means "the window has actually been resized".

If I am right, the first means "the window isn't resized yet",
which means I can countermand the user from program control.

Whereas the second has a vital significance: it means the
SDL_Window's SDL_Surface is invalid and must not be used.
So a new surface must be fetched corresponding to the new window,
and then painted and the window updated.

Now the point of the above guess is that the response to the events
is different. Which means I need to know which is which.

And since I get both events to avoid duplication, I need to ignore one
of them. I haven't tried a program controlled resize yet so I have
no data.

But really, the header file documentation should be edited to
explain the difference.

--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
gabomdq


Joined: 28 Jul 2011
Posts: 495
Location: Argentina
Post Posted: Sun Aug 04, 2013 2:36 pm
2013/8/3 john skaller
Quote:

On 04/08/2013, at 12:13 AM, David Gow wrote:

Quote:
As I understand it, SDL_WINDOWEVENT_SIZE_CHANGED is sent when you explicitly resize the window using SDL_SetWindowSize() or similar (changing fullscreen resolutions, for example), whereas SDL_WINDOWEVENT_RESIZED is sent when the window is resized by something other than a direct API call. It's been a while since I looked at that code though, so I could be wrong, though.

In any case, you shouldn't have any problems just handling both of them.


This makes sense, but I would like an authoritative response.





My answer is by no means authoritative but I've looked into this recently. My understanding is that SDL_WINDOWEVENT_RESIZED is sent when something external to SDL (the user dragging the window corner, a device rotation on Android) changes the window size. SDL_WINDOWEVENT_SIZE_CHANGED is sent from SDL_OnWindowResized when SDL "finishes" internally processing this external size change *or an internally requested one*.


So, if you request a window size change (by going fullscreen, by using SDL_SetWindowSize), you'll only receive SDL_WINDOWEVENT_SIZE_CHANGED. If something external to your app initiates the change, you'll get both SDL_WINDOWEVENT_RESIZED first and SDL_WINDOWEVENT_SIZE_CHANGED when SDL completes the internal processing of this event.


Quote:

But really, the header file documentation should be edited to
explain the difference.



If you make a patch for this, upload to Bugzilla and I'll review it and incorporate it. Thanks!



--
Gabriel.
resize
john skaller
Guest
Post Posted: Sun Aug 04, 2013 10:17 pm
On 05/08/2013, at 12:36 AM, Gabriel Jacobo wrote:
Quote:

My answer is by no means authoritative but I've looked into this recently.

So it's based on a study of the implementation as opposed to documented
intent.

Quote:
My understanding is that SDL_WINDOWEVENT_RESIZED is sent when something external to SDL (the user dragging the window corner, a device rotation on Android) changes the window size. SDL_WINDOWEVENT_SIZE_CHANGED is sent from SDL_OnWindowResized when SDL "finishes" internally processing this external size change *or an internally requested one*.

So, if you request a window size change (by going fullscreen, by using SDL_SetWindowSize), you'll only receive SDL_WINDOWEVENT_SIZE_CHANGED. If something external to your app initiates the change, you'll get both SDL_WINDOWEVENT_RESIZED first and SDL_WINDOWEVENT_SIZE_CHANGED when SDL completes the internal processing of this event.

Ok, thanks!

So, since a window surface is invalidated by a size change,
SDL_WINDOWEVENT_SIZE_CHANGED is
the proper message to trigger refetching the surface.

I can't think of a use for SDL_WINDOWEVENT_RESIZED now,
since that occurs afterwards, and presumably a program "knows"
when it requests a resize. Hmm .. well maybe it doesn't .. Smile


--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
Sik


Joined: 26 Nov 2011
Posts: 905
Post Posted: Sun Aug 04, 2013 10:58 pm
2013/8/4, john skaller:
Quote:
I can't think of a use for SDL_WINDOWEVENT_RESIZED now,
since that occurs afterwards, and presumably a program "knows"
when it requests a resize. Hmm .. well maybe it doesn't .. Smile

It can become cumbersome keeping track of whether the program caused
the event or something from outside (you need to set a flag somewhere
and then check it in the event handler, and finding a good place where
to put that flag without ugly design can be a problem - not everybody
likes globals).

A flag common to all events indicating whether it came from a program
action or external action would be very useful (let SDL track it
instead of the program). No idea if it's possible to add without
breaking the ABI though...
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
John
Guest
Post Posted: Mon Aug 05, 2013 8:36 pm
The various SDL events aren't delivered for every platform (or even for the same
platform) and when they are delivered, they are not in any particular order.
The best you can do is be prepared to handle all the events, but do not ever
*expect* them.

For example, on Linux, when a window is resized, the app will receive the event
sequence {LEAVE, FOCUS_LOST, MOVED, (RESIZED, EXPOSED)*... FOCUS_GAINED, ENTER}
depending upon the flavor of Linux and the desktop focus policy. On Android,
when you fix the orientation in the build xml config, the app will receive
SIZE_CHANGED but not RESIZED. However, on the same device, when you do not fix
the orientation, the opposite occurs, and the app will receive RESIZED but not
SIZE_CHANGED.

The only thing you can expect is that the events can (and will) change at any
time during SDL's development.


On 08/04/2013 06:58 PM, Sik the hedgehog wrote:
Quote:
2013/8/4, john skaller:
Quote:
I can't think of a use for SDL_WINDOWEVENT_RESIZED now,
since that occurs afterwards, and presumably a program "knows"
when it requests a resize. Hmm .. well maybe it doesn't .. Smile

It can become cumbersome keeping track of whether the program caused
the event or something from outside (you need to set a flag somewhere
and then check it in the event handler, and finding a good place where
to put that flag without ugly design can be a problem - not everybody
likes globals).

A flag common to all events indicating whether it came from a program
action or external action would be very useful (let SDL track it
instead of the program). No idea if it's possible to add without
breaking the ABI though...
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
john skaller
Guest
Post Posted: Tue Aug 06, 2013 1:56 pm
On 06/08/2013, at 6:36 AM, John wrote:

Quote:
The various SDL events aren't delivered for every platform (or even for the same platform) and when they are delivered, they are not in any particular order. The best you can do is be prepared to handle all the events, but do not ever *expect* them.

For example, on Linux, when a window is resized, the app will receive the event sequence {LEAVE, FOCUS_LOST, MOVED, (RESIZED, EXPOSED)*... FOCUS_GAINED, ENTER} depending upon the flavor of Linux and the desktop focus policy. On Android, when you fix the orientation in the build xml config, the app will receive SIZE_CHANGED but not RESIZED. However, on the same device, when you do not fix the orientation, the opposite occurs, and the app will receive RESIZED but not SIZE_CHANGED.

The only thing you can expect is that the events can (and will) change at any time during SDL's development.



Alright so how about this: handle both the same way, but check if the new size
equals the old size before acting.


--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
John
Guest
Post Posted: Wed Aug 07, 2013 4:07 pm
Yes, but also track whether you've seen the first event (of either one). On some
platforms or device configurations, you get a resized or size_changed event when
first launching the app, but on others you do not.


On 08/06/2013 09:55 AM, john skaller wrote:
Quote:

On 06/08/2013, at 6:36 AM, John wrote:

Quote:
The various SDL events aren't delivered for every platform (or even for the
same platform) and when they are delivered, they are not in any particular
order. The best you can do is be prepared to handle all the events, but do
not ever *expect* them.

For example, on Linux, when a window is resized, the app will receive the
event sequence {LEAVE, FOCUS_LOST, MOVED, (RESIZED, EXPOSED)*...
FOCUS_GAINED, ENTER} depending upon the flavor of Linux and the desktop
focus policy. On Android, when you fix the orientation in the build xml
config, the app will receive SIZE_CHANGED but not RESIZED. However, on the
same device, when you do not fix the orientation, the opposite occurs, and
the app will receive RESIZED but not SIZE_CHANGED.

The only thing you can expect is that the events can (and will) change at
any time during SDL's development.



Alright so how about this: handle both the same way, but check if the new
size equals the old size before acting.


-- john skaller http://felix-lang.org



_______________________________________________ SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
john skaller
Guest
Post Posted: Wed Aug 07, 2013 8:20 pm
On 08/08/2013, at 2:00 AM, John wrote:

Quote:
Yes, but also track whether you've seen the first event (of either one). On some platforms or device configurations, you get a resized or size_changed event when first launching the app, but on others you do not.

Quote:

Alright so how about this: handle both the same way, but check if the new
size equals the old size before acting.


How exactly would I "track" this other than by a size comparison?

Indeed it isn't clear to me what happens if you're drawing on said
surface and in the middle the user resizes the window. What happens
then?


--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
John
Guest
Post Posted: Wed Aug 07, 2013 10:24 pm
Comparing the size seems sketchy because it imagine it's possible to
re-initialize a window with the same size, triggering a "resize" event. The new
window would have the same size as the old one, but still require the app to
re-initialize it or allocate new textures. That's all speculation.


After a resize, you should assume your drawing surfaces are invalid. GL textures
are probably ok and do not need to be reinitialized, but I don't know for
sure... there may be legacy weirdness leftover from the DirectDraw days when
surfaces could be "lost" at any time.


On 08/07/2013 04:19 PM, john skaller wrote:
Quote:

On 08/08/2013, at 2:00 AM, John wrote:

Quote:
Yes, but also track whether you've seen the first event (of either one). On some platforms or device configurations, you get a resized or size_changed event when first launching the app, but on others you do not.

Quote:

Alright so how about this: handle both the same way, but check if the new
size equals the old size before acting.


How exactly would I "track" this other than by a size comparison?

Indeed it isn't clear to me what happens if you're drawing on said
surface and in the middle the user resizes the window. What happens
then?


--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
Jonas Kulla
Guest
Post Posted: Thu Aug 08, 2013 1:40 am
2013/8/8 John
Quote:
After a resize, you should assume your drawing surfaces are invalid. GL textures are probably ok and do not need to be reinitialized, but I don't know for sure... there may be legacy weirdness leftover from the DirectDraw days when surfaces could be "lost" at any time.
 

I think that's what used to happened with pbuffers. Thank Khronos we have FBOs these days Very Happy
resize
Rainer Deyke
Guest
Post Posted: Thu Aug 08, 2013 4:02 am
On 07.08.2013 22:19, john skaller wrote:
Quote:
Indeed it isn't clear to me what happens if you're drawing on said
surface and in the middle the user resizes the window. What happens
then?

You can continue drawing (i.e. the surface continues to exist and keeps
its dimensions), but SDL_UpdateWindowSurface and
SDL_UpdateWindowSurfaceRects will return an error until you call
SDL_GetWindowSurface to get a new window surface (at which point the old
surface is destroyed).


--
Rainer Deyke
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
john skaller
Guest
Post Posted: Thu Aug 08, 2013 9:57 am
On 08/08/2013, at 2:02 PM, Rainer Deyke wrote:

Quote:
On 07.08.2013 22:19, john skaller wrote:
Quote:
Indeed it isn't clear to me what happens if you're drawing on said
surface and in the middle the user resizes the window. What happens
then?

You can continue drawing (i.e. the surface continues to exist and keeps its dimensions), but SDL_UpdateWindowSurface and SDL_UpdateWindowSurfaceRects will return an error until you call SDL_GetWindowSurface to get a new window surface (at which point the old surface is destroyed).


This makes sense for a software renderer, but what about a hardware (accelerated)
one?

So if I understand, you can draw on a surface which may asynchronously become
invalid (in the sense the update will fail). Which is no big deal.

--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
Rainer Deyke
Guest
Post Posted: Thu Aug 08, 2013 10:50 am
On 05.08.2013 22:36, John wrote:
Quote:
The various SDL events aren't delivered for every platform (or even for
the same platform) and when they are delivered, they are not in any
particular order. The best you can do is be prepared to handle all the
events, but do not ever *expect* them.

For example, on Linux, when a window is resized, the app will receive
the event sequence {LEAVE, FOCUS_LOST, MOVED, (RESIZED, EXPOSED)*...
FOCUS_GAINED, ENTER} depending upon the flavor of Linux and the desktop
focus policy. On Android, when you fix the orientation in the build xml
config, the app will receive SIZE_CHANGED but not RESIZED. However, on
the same device, when you do not fix the orientation, the opposite
occurs, and the app will receive RESIZED but not SIZE_CHANGED.

I'm pretty sure that's not true, at least not in the current Mercurial
version. Every SDL video driver posts RESIZED events when it receives
an external resize event (i.e. the user resizes the window directly).
This always goes through SDL_SendWindowEvent, which always calls
SDL_OnWindowResized, which in turn always posts a SIZE_CHANGED event.
SDL_OnWindowResized is also called by e.g. SDL_SetWindowSize. In other
words, you should always receive both a RESIZE and a SIZE_CHANGED event,
in that order, if the user resizes a window, and you should always
receive just the SIZE_CHANGED event when you change the window size
directly with SDL_SetWindowSize.


--
Rainer Deyke
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
Rainer Deyke
Guest
Post Posted: Thu Aug 08, 2013 3:58 pm
On 06.08.2013 15:55, john skaller wrote:
Quote:
Alright so how about this: handle both the same way, but check if the new size
equals the old size before acting.

That's actually not correct. When a new RESIZED or SIZE_CHANGED event
is enqueued, all old events of the same type are discarded from the
queue. This means that the window surface could have been invalidated
even if you only receive RESIZED and SIZE_CHANGED events where the old
size is the same as the new size.


--
Rainer Deyke
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
john skaller
Guest
Post Posted: Fri Aug 09, 2013 12:18 am
On 08/08/2013, at 8:50 PM, Rainer Deyke wrote:

Quote:
In other words, you should always receive both a RESIZE and a SIZE_CHANGED event, in that order, if the user resizes a window,


Er, on OSX the resized event comes second: here's evidence from
my program:

WindowEvent leave
WindowEvent enter
WindowEvent size_changed
WindowEvent resized
WindowEvent leave
WindowEvent enter


--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
Rainer Deyke
Guest
Post Posted: Fri Aug 09, 2013 5:22 am
On 09.08.2013 02:17, john skaller wrote:
Quote:

On 08/08/2013, at 8:50 PM, Rainer Deyke wrote:

Quote:
In other words, you should always receive both a RESIZE and a
SIZE_CHANGED event, in that order, if the user resizes a window,


Er, on OSX the resized event comes second: here's evidence from my
program:

Yes, I was mistaken about the order. SDL_SendWindowEvent actually calls
SDL_OnWindowResized before SDL_PushEvent, so the SIZE_CHANGED event
actually comes before the RESIZE event (consistently, on all platforms).


--
Rainer Deyke
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
john skaller
Guest
Post Posted: Fri Aug 09, 2013 6:40 am
On 09/08/2013, at 3:22 PM, Rainer Deyke wrote:

Quote:
On 09.08.2013 02:17, john skaller wrote:
Quote:

On 08/08/2013, at 8:50 PM, Rainer Deyke wrote:

Quote:
In other words, you should always receive both a RESIZE and a
SIZE_CHANGED event, in that order, if the user resizes a window,


Er, on OSX the resized event comes second: here's evidence from my
program:

Yes, I was mistaken about the order. SDL_SendWindowEvent actually calls SDL_OnWindowResized before SDL_PushEvent, so the SIZE_CHANGED event actually comes before the RESIZE event (consistently, on all platforms).


Ok, so logically:

SIZE_CHANGED invalidates the current surface and allows you to grab a new one.

What is the use of RESIZE? is this just a legacy event?

--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
Rainer Deyke
Guest
Post Posted: Fri Aug 09, 2013 7:23 am
On 09.08.2013 08:39, john skaller wrote:
Quote:
What is the use of RESIZE? is this just a legacy event?

RESIZE allows you to differentiate between user-triggered and
self-triggered window size changes, since only the former post RESIZE
events. For example, you can respond to a RESIZE event by calling
SDL_SetWindowSize without worrying about triggering an infinite loop.
This can be useful if you want to allow resizing, but want to maintain a
particular aspect ratio for your window.


--
Rainer Deyke
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
resize
john skaller
Guest
Post Posted: Fri Aug 09, 2013 7:56 am
On 09/08/2013, at 5:23 PM, Rainer Deyke wrote:

Quote:
On 09.08.2013 08:39, john skaller wrote:
Quote:
What is the use of RESIZE? is this just a legacy event?

RESIZE allows you to differentiate between user-triggered and self-triggered window size changes, since only the former post RESIZE events. For example, you can respond to a RESIZE event by calling SDL_SetWindowSize without worrying about triggering an infinite loop. This can be useful if you want to allow resizing, but want to maintain a particular aspect ratio for your window.


Good point!

--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org