We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

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.

Created attachment 70 [details]
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 <driver>_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.

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.

(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.

(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 ?

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.

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.