resize |
john skaller
Guest
|
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
|
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:
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
resize |
john skaller
Guest
|
On 04/08/2013, at 12:13 AM, David Gow wrote:
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 |
resize |
john skaller
Guest
|
On 05/08/2013, at 12:36 AM, Gabriel Jacobo wrote:
So it's based on a study of the implementation as opposed to documented intent.
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 .. -- john skaller http://felix-lang.org _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
resize |
Sik
|
2013/8/4, john skaller:
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
|
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:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
resize |
john skaller
Guest
|
On 06/08/2013, at 6:36 AM, John wrote:
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
|
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:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
resize |
john skaller
Guest
|
On 08/08/2013, at 2:00 AM, John wrote:
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
|
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:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
resize |
Jonas Kulla
Guest
|
2013/8/8 John
I think that's what used to happened with pbuffers. Thank Khronos we have FBOs these days |
|||||||||||||
|
resize |
Rainer Deyke
Guest
|
On 07.08.2013 22:19, john skaller wrote:
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
|
On 08/08/2013, at 2:02 PM, Rainer Deyke wrote:
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
|
On 05.08.2013 22:36, John wrote:
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
|
On 06.08.2013 15:55, john skaller wrote:
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
|
On 08/08/2013, at 8:50 PM, Rainer Deyke wrote:
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
|
On 09.08.2013 02:17, john skaller wrote:
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
|
On 09/08/2013, at 3:22 PM, Rainer Deyke wrote:
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
|
On 09.08.2013 08:39, john skaller wrote:
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
|
On 09/08/2013, at 5:23 PM, Rainer Deyke wrote:
Good point! -- john skaller http://felix-lang.org _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|