Videoresize

Am I the only one who is having trouble resizing SDL 1.2 windows?

It seems like just handling SDL_VIDEORESIZE events sometimes leaves me one
step behind, never actually getting the final size. I end up with an SDL
context that isn’t exactly matching the actual client area of the window. This
happens with “SDL 2D” as well as OpenGL.

(Gentoo (ex Sabayon) Linux x86_64 with SDL 1.2.14-r6 and KDE KWin 4.5.5.)

Not generally a showstopper issue, but the error can be a factor two or so
when switching between windowed and fullscreen modes…! Can’t have that, so
I’ll need to find some solution or workaround…–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

Not generally a showstopper issue, but the error can be a factor two or so
when switching between windowed and fullscreen modes…! Can’t have that, so
I’ll need to find some solution or workaround…

Wait until you haven’t gotten a resize event for 500 milliseconds, then
call SDL_SetVideoMode() to catch up?

I imagine some window managers positively flood the app with resize
events, so it might be good to wait until they calm down to do something
about them.

–ryan.

While that makes resizing smoother and more efficient, it doesn’t solve the
problem, unfortunately. Whether I just process the whole event queue before
handling the resize, or wait for some 500 ms doesn’t seem to matter. I still
end up with an incorrect display size for the window. If I “fix” that later,
the window is resized, rather than the display area being corrected.

Another interesting observation, though: It seems like the events are not
really lost, but rather stuck somewhere! And not just those events: When this
happens, mouse moves go through (application rendered cursor moves around),
but if I then press a mouse button, I get that resize event just before the
mouse down event.

Not sure what to make of that. Is that my WM having fun, or SDL trying to do
some sort of filtering?On Friday 11 November 2011, at 21.46.02, “Ryan C. Gordon” wrote:

Not generally a showstopper issue, but the error can be a factor two or
so when switching between windowed and fullscreen modes…! Can’t have
that, so I’ll need to find some solution or workaround…

Wait until you haven’t gotten a resize event for 500 milliseconds, then
call SDL_SetVideoMode() to catch up?


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

[…]

Another interesting observation, though: It seems like the events are not
really lost, but rather stuck somewhere! And not just those events: When
this happens, mouse moves go through (application rendered cursor moves
around), but if I then press a mouse button, I get that resize event just
before the mouse down event.
[…]

Actually, not correct; it’s not just that. It’s when I process that mouse
click and do… something. I have yet to figure out exactly what it is that
triggers this mysterious release of the stuck resize event. Off to investigate
that…On Friday 11 November 2011, at 23.10.26, David Olofson <@David_Olofson> wrote:


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’