SDL - OpenGL Resize bug under Windows

SDL Development
1

Dear SDL users,

I’m confronted to the well known bug relative to the resize of a SDL window
: all textures disappear from screen. I carefully read the SDL ml archive
before the post and it seems that OpengL context is destroyed at each
SDL_SetVideo function call.

I have a few questions dealing with this problem:

  • is a bugfix planned in a future release of SDL?

*did anyone try the wglCopyContext function (from the WGL extensions) to
copy opengl current context to a temporary one before it is destroyed, and
resore it after the SDL_SetVideo call?

*In other case, is it a way to share opengl infos (such as display lists and
textures) between 2 different context?

Anyway, what are the possible strategies to pass through this bug?

Thanks for your answers abd your experience share

Thomas------------------------------------------------------------------------------------
Visit Soya 3D engine home page:
http://home.gna.org/oomadness/en/soya/index.html

2

Thomas Paviot wrote:

Dear SDL users,

I’m confronted to the well known bug relative to the resize of a SDL
window : all textures disappear from screen. I carefully read the SDL ml
archive before the post and it seems that OpengL context is destroyed at
each SDL_SetVideo function call.

I have a few questions dealing with this problem:

  • is a bugfix planned in a future release of SDL?

AFAIK, this is not a bug, it’s documented behavior of the windows OpenGL
implementation. So it probably won’t get fixed.

AFAIK, the OpenGL specs allow this, too.

Thomas

-Sebastian

3

Sebastian Beschke wrote:

Thomas Paviot wrote:

Dear SDL users,

I’m confronted to the well known bug relative to the resize of a SDL
window : all textures disappear from screen. I carefully read the SDL
ml archive before the post and it seems that OpengL context is
destroyed at each SDL_SetVideo function call.

I have a few questions dealing with this problem:

  • is a bugfix planned in a future release of SDL?

AFAIK, this is not a bug, it’s documented behavior of the windows OpenGL
implementation. So it probably won’t get fixed.

AFAIK, the OpenGL specs allow this, too.

This “bug” occurs somewhere in Microsoft’s code or your drivers - I
suspect the former. That’s not the domain of the SDL library to fix,
unfortunately. The workaround is to simply reload your textures. The two
options SDL has are:

  1. Saving all textures to a buffer before sending them to video memory.
    This will cause a performance hit to often-updated textures.

  2. Attempt to grab the texture from video memory on context switch. This
    will cause more overhead than simply re-sending the textures from system
    memory, assuming those textures have allready been loaded.

  3. Ignore the problem, and let programs deal with it - with no extra
    overhead, since those programs allready have expert knowledge of the
    situation of it’s textures.

AFAIK, SDL has gone with #3. Rationale being: Texture reloading is easy
to implement in userland with C or C++, and allows your program faster
operation. That, and we don’t want to break backwards compatibility -
the relevant opengl calls would be routed through SDL, meaning the
texture-reloading might not work for older binaries.

-Mike

4

[…]

Well, I’d consider it a “bug” in SDL as it is possible to resize your window
without recreating the OpenGL context (even on windows).
Only if you change other properties (video depth, etc), your context will
become invalid.
But changing the default SDL behaviour (destroying the context on windows on
every call to SDL_SetVideoMode) might break applications (in terms of video
memory management).

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI ToolkitOn Friday 26 November 2004 23:25, Michael B. Edwin Rickert wrote:

Sebastian Beschke wrote:

Thomas Paviot wrote:

Dear SDL users,

I’m confronted to the well known bug relative to the resize of a SDL
window : all textures disappear from screen. I carefully read the SDL
ml archive before the post and it seems that OpengL context is
destroyed at each SDL_SetVideo function call.

I have a few questions dealing with this problem:

  • is a bugfix planned in a future release of SDL?

AFAIK, this is not a bug, it’s documented behavior of the windows OpenGL
implementation. So it probably won’t get fixed.

AFAIK, the OpenGL specs allow this, too.

This “bug” occurs somewhere in Microsoft’s code or your drivers - I
suspect the former.

5

Le Sat, 27 Nov 2004 11:35:23 +0100
Johannes Schmidt a ?crit:

Well, I’d consider it a “bug” in SDL as it is possible to resize your
window without recreating the OpenGL context (even on windows).
Only if you change other properties (video depth, etc), your context
will become invalid.

Yes, the OSMesa (offscreen rendering) driver behaves like this. A simple
resize just need a new SDL_GL_MakeCurrent() call to update some
properties. I use it for the Atari platform, and before destroying the
context on SetVideoMode(), I check if the context properties are the same
or not. This way, simply resizing the SDL window won’t flush display lists
and textures.

But changing the default SDL behaviour (destroying the context on
windows on every call to SDL_SetVideoMode) might break applications (in
terms of video memory management).

Yes it might break it. I was thinking about adding a new event, something
like SDL_NEWOPENGLCONTEXT, when the context has been destroyed and
recreated. This way, all SDL video drivers could tell the application if
the context has been destroyed or not. New applications could use it, and
current/old applications will behave the same.–
Patrice Mandin
WWW: http://membres.lycos.fr/pmandin/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux