Resize

a3bm() {

Hi! How can i display on a SDL_Surface another one with a different
size? I mean, something like a zoom, for example.

F.

}–
Key fingerprint = 7A 81 0A 0C 0D 58 4E E3 57 96 70 AA ED C7 29 E7

?.(?. * <@Federico_Joselevich> * .?).?)

a3bm() {

Hi! How can i display on a SDL_Surface another one with a different
size? I mean, something like a zoom, for example.

This isn’t supported natively by SDL, but the SDL_gfx library has a
"rotozoomer" that can do it.

– JoshOn 9/6/05, Federico Joselevich <imnotmork_listas at area3.net> wrote:

F.

}


Key fingerprint = 7A 81 0A 0C 0D 58 4E E3 57 96 70 AA ED C7 29 E7

?.(?. * <imnotmork_listas at area3.net> * .?).?)


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

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
@john_skaller
http://felix-lang.org

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.

– DavidOn 03/08/13 22:07, john skaller wrote:

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
skaller at users.sourceforge.net
http://felix-lang.org


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

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.On 04/08/2013, at 12:13 AM, David Gow wrote:


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

2013/8/3 john skaller

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.

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!> On 04/08/2013, at 12:13 AM, David Gow wrote:


Gabriel.

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.

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 … :)On 05/08/2013, at 12:36 AM, Gabriel Jacobo wrote:


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

2013/8/4, john skaller :

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 … :slight_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…

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:

2013/8/4, john skaller :

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 … :slight_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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.On 06/08/2013, at 6:36 AM, John wrote:


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

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:

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

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 skaller at users.sourceforge.net http://felix-lang.org

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

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.

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?On 08/08/2013, at 2:00 AM, John wrote:


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

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:

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

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.

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
skaller at users.sourceforge.net
http://felix-lang.org


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

2013/8/8 John

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 :smiley:

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).On 07.08.2013 22:19, john skaller wrote:

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?


Rainer Deyke (rainerd at eldwood.com)

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.On 08/08/2013, at 2:02 PM, Rainer Deyke wrote:

On 07.08.2013 22:19, john skaller wrote:


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

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.On 05.08.2013 22:36, John wrote:

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.


Rainer Deyke (rainerd at eldwood.com)

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.On 06.08.2013 15:55, john skaller wrote:

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


Rainer Deyke (rainerd at eldwood.com)

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 enterOn 08/08/2013, at 8:50 PM, Rainer Deyke wrote:


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

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).On 09.08.2013 02:17, john skaller wrote:

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


Rainer Deyke (rainerd at eldwood.com)