SDL_SetVideoMode and OpenGL contexts

I’m wondering what the difference is between the Linux and Windows
versions of SDL that mean that I can resize a window without trouble in
Linux but even the slightest change of size in Windows annihilates the
data.

Also, is there any data asides from the textures that may need to be
reloaded such as display lists or lights?___________________________________________________________
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

I think it’s more of a limitation of OpenGL, and not really SDL’s
fault. Under Windows the OpenGL state can get lost pretty easily. I’d
recommend reloading it entirely just to be sure, at least under
Windows.On 1/29/07, Paul Duffy wrote:

I’m wondering what the difference is between the Linux and Windows
versions of SDL that mean that I can resize a window without trouble in
Linux but even the slightest change of size in Windows annihilates the
data.

Also, is there any data asides from the textures that may need to be
reloaded such as display lists or lights?

  • SR

I’m wondering what the difference is between the Linux and Windows
versions of SDL that mean that I can resize a window without trouble in
Linux but even the slightest change of size in Windows annihilates the
data.

It isn’t a difference in SDL. It is a difference between the OpenGL
implementations on Linux and Windows.

BTW, this questions (and it does qualify as a FAQ) often leads to a
flame war… so lets try to avoid that this time around.

Also, is there any data asides from the textures that may need to be
reloaded such as display lists or lights?

Reload your entire context, it was all lost.

A technique that I have used in the past is to create a context manager
layer. That is basically a replacement for every OpenGL context function
I use in a program. This layer maintains a “shadow” copy of all the
values I have set. Then you have one function that can reset the OpenGL
context from the shadow context. This layer can also be used to reduce
sending redundant context changes down the pipe.

	Bob PendletonOn Mon, 2007-01-29 at 14:16 +0000, Paul Duffy wrote:

Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html


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


±-------------------------------------+

It isn’t a difference in SDL. It is a difference between the OpenGL
implementations on Linux and Windows.

Seems a bit odd to me, but I don’t know much about the inner workings of
OpenGL.

BTW, this questions (and it does qualify as a FAQ) often leads to a
flame war… so lets try to avoid that this time around.

OS bashing by any chance? As for the FAQ, I think the WIKI might have
been able to answer my question, but that’s currently down and I
couldn’t find anything in my e-mail archive.

Also, is there any data asides from the textures that may need to be
reloaded such as display lists or lights?

Reload your entire context, it was all lost.

Badgers.

Thanks Bob and Simon for both your replies.On Mon, 2007-01-29 at 09:30 -0600, Bob Pendleton wrote:


All new Yahoo! Mail “The new Interface is stunning in its simplicity and ease of use.” - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html

Le 29 janv. 07 ? 15:40, Simon Roby a ?crit :

I think it’s more of a limitation of OpenGL, and not really SDL’s
fault. Under Windows the OpenGL state can get lost pretty easily.

Note that the same loss occurs when resizing windows on macosx but I
can guarantee you that this is not a limitation of macosx’s opengl
implementation. So at least on macosx it is SDL’s fault if you lose
your context each time you resize.

But I think 1.3 will change this (I also hope we will get state
sharing between fullscreen and windowed gl contexts on platforms that
support it).

Best,

Daniel

I’m wondering what the difference is between the Linux and Windows
versions of SDL that mean that I can resize a window without trouble in
Linux but even the slightest change of size in Windows annihilates the
data.

I develop on linux (Slackware) and compile on Windows later (for my
friends to see the marvels I make). I do the exact same procedures on
Linux and Windows, so that my program is totally abstract from whichever
OS it’s running on. Thanks to SDL and OpenGL this paradise has been
made possible! :wink:

Something interesting to note, is that I run these programs on my own
computer (I own only one) and I just reboot between linux and windows.
The problem you mention does happen on windows not on linux and this
said, you might understand it is not a limitation of the hardware (since
it’s the same), it’s probably not a limitation of the driver (since it’s
the same company: nvidia), it’s not a limitation of SDL as I compile the
same source on both OS. And it’s not a limitation of my programming as
it’s the same source as well. The only difference that’s left is the
OS. This said, i read other replies and they made me remember… it is
not a limitation, it is defined in opengl (if i remember correctly) as
being a something left to the OS and opengl only gives the general
guideline to re-upload textures regardless if the os can do it or not.

I also remember some one telling me it is best to first delete or free
the textures from the video ram and then change the video mode, then
re-upload. I do not know if all these steps are necessary of if the
freeing is done by the change of the vmode.

Also, is there any data asides from the textures that may need to be
reloaded such as display lists or lights?

I think the rule of thumb is: anything that is “resident” on the card.
Textures for sure, but display lists sounds good as well, I never played
with lights but if you “record” their settings in any way I guess it’s
better to reupload.

Happy coding!
Simon

Something interesting to note, is that I run these programs on my own
computer (I own only one) and I just reboot between linux and windows.
The problem you mention does happen on windows not on linux and this
said, you might understand it is not a limitation of the hardware (since
it’s the same), it’s probably not a limitation of the driver (since it’s
the same company: nvidia), it’s not a limitation of SDL as I compile the
same source on both OS. And it’s not a limitation of my programming as

Actually, this is a limitation of SDL. When your application receives a
resize event, you’re supposed to call SDL_SetVideoMode to resize
everything accordingly. With the current (SDL 1.2) implementations on
Windows and OS X, SDL_SetVideoMode destroys the current GL context and
creates a new one, even though it might had been possible to reuse it.
Using lower-level platform-specific APIs, one might be able to overcome
this in many cases.

The long-term solution would be to make the resizing behaviour to try to
retain the GL context as far as possible (although whether this really is
possible in all difficult cases, e.g. when going from fullscreen to
windowed mode or vice versa depends on the platform-specific APIs), but it
has also been discussed adding some kind of event telling the application
that the GL context was lost. (What was the outcome of that discussion?)

Also, is there any data asides from the textures that may need to be
reloaded such as display lists or lights?

I think the rule of thumb is: anything that is “resident” on the card.
Textures for sure, but display lists sounds good as well, I never played
with lights but if you “record” their settings in any way I guess it’s
better to reupload.

Not only textures or display lists are lost, the whole GL context is lost,
including modelview/projection matrices, lighting parameters, current
color, material parameters, everything.

// MartinOn Mon, 29 Jan 2007, Simon wrote:

Actually, this is a limitation of SDL. When your application receives a
resize event, you’re supposed to call SDL_SetVideoMode to resize
everything accordingly. With the current (SDL 1.2) implementations on
Windows and OS X, SDL_SetVideoMode destroys the current GL context and
creates a new one, even though it might had been possible to reuse it.
Using lower-level platform-specific APIs, one might be able to overcome
this in many cases.

I think I wanted to something like that using different words.

What I was outlining is that SDL has trouble keeping the OpenGL context
on some OS. Is it SDL’s fault? I have trouble climbing a skyscrapper,
is it my fault? Well, yea it is, in some way. But I agree that SDL (in
its quest for OS-abstraction) should try to fix this OS-related bug.

I think a simple test would be to upload a 2x2 texture with specific
colors, then later, query to see if the texture is still there and read
the colors. If I remember correctly, OpenGL will let you use and
manipulate a texture that does not exist, and most of the time (the
times I did it by mistake) the texture is black (or white? multiplies
color by 1 or 0?).

Just a thought here,
Simon