Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inform applications about OpenGL context recreation #32

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

Inform applications about OpenGL context recreation #32

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Labels
endoflife Bug might be valid, but SDL-1.2 is EOL.

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 1.2
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-10 17:10:05 +0000, Patrice Mandin wrote:

Not all OpenGL implementations used by SDL destroy and recreate the OpenGL context when SDL_SetVideoMode() is called, or when the application window is resized.

My proposal was to add two things in SDL:

  • Set a bit in SDL_Surface screen flag that tells that the OpenGL context has been kept (leave it to zero if context has been destroyed, so all current applications still don't care about it).
  • Add a new event to tell that the OpenGL context has been destroyed and recreated. This is when the window is resized, because the application does not call SDL_SetVideoMode() in this case.

Currently some applications has some #ifdef WIN32 part of code to force reloading everything related to the OpenGL context (textures, display lists, etc...) when either SDL_SetVideoMode() is called or the application window is resized. This topic is platform-dependent, so it should be hidden inside SDL.

The topic comes back once in a while, see an older one:
http://www.devolution.com/pipermail/sdl/2004-November/065847.html

On 2006-01-27 11:23:13 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-02-07 16:58:11 +0000, Patrice Mandin wrote:

Created attachment 70
Definition of a flag for screen surface, and example setting it for x11 driver

OK, here is the small patch. I add a new flag for the SDL_Surface screen
flag. The flag is cleared before calling any _SetVideoMode. Then
it is the responsibility of the driver to set the flag if the OpenGL
context has been kept (not destroyed). I added the small patch for the
x11 driver. Then, the application can check this bit to see if the
OpenGL context has been destroyed or not. So now we can have:

  • Old applications with new SDL: Don't care about the bit
  • New applications with old SDL: Always see the bit as zero, so behave
    the same.
  • New applications with new SDL: What we intended.

Both windib and windx5 always destroy the context, I don't know about
other video drivers. At least, for my part (using OSMesa on Atari),
simply resizing the context does not destroy it, so I will do this part
myself.

Also, it seems there is no need for a special event, as SDL_VIDEORESIZE
only tell about the new size, and the application must call
SDL_SetVideoMode().

Of course, any comments are welcomed.

On 2006-02-07 20:42:03 +0000, Ryan C. Gordon wrote:

My only concern is that it's possible to lose hardware surfaces on Windows completely outside the control of your application...are we SURE there's no time other than SetVideoMode where the GL context can be lost?

--ryan.

On 2006-02-08 12:28:01 +0000, Sam Lantinga wrote:

(In reply to comment # 3)

My only concern is that it's possible to lose hardware surfaces on Windows
completely outside the control of your application...are we SURE there's no
time other than SetVideoMode where the GL context can be lost?

I believe that's the case, and even when the window is resized it isn't lost, it's only when the fullscreen video mode changes, which is under the application's control.

I'd like to hold off on this patch, in the hope that we can have different code paths for window resizing and setting new video modes in SDL 1.3. Currently everyone always re-creates their OpenGL state when they call SDL_SetVideoMode(), which is the safe thing to do.

On 2006-02-16 11:16:21 +0000, Gerry JJ wrote:

(In reply to comment # 4)

I believe that's the case, and even when the window is resized it isn't lost,
it's only when the fullscreen video mode changes, which is under the
application's control.

What happens if the SDL app runs in a window while a different app switches the fullscreen video mode ?

On 2011-12-30 00:29:46 +0000, Ryan C. Gordon wrote:

I'm going to close this as WONTFIX for 1.2, since the 1.3 API handles this properly, and I don't think we should make changes like this to 1.2 at this point.

--ryan.

On 2015-08-25 09:38:22 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email (icculus@icculus.org) and we'll try to find some way to help you out of your situation.

Thank you,
--ryan.

@SDLBugzilla SDLBugzilla added bug endoflife Bug might be valid, but SDL-1.2 is EOL. labels Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
endoflife Bug might be valid, but SDL-1.2 is EOL.
Projects
None yet
Development

No branches or pull requests

1 participant