Right now I’m trying to make a small library to be used in utility applications with fancy UI and little games.
I’m making it using OpenGL on top of SDL.
On windows there are no problems with resizable window.
I’m just updating viewport and it works fine.
On mac os x it’s broken.
When I resize window, picture is moved in some random way, new space is flickering with garbage and updating viewport do not help at all.
After digging for some time in SDL sources and various OpenGL samples for mac os x,
I’ve found out that after window resize you need to call ‘update’ method on opengl context.
As a quick hack I’ve added:
Code:
[ gl_context update];
to setFrame method at src/video/quartz/SDL_QuartzWindow.m:129
and it seems to fix the problem.
Probably it is valid solution.
I’ve heard that 1.2 was frozen… Is there a chance that fixed version will come out,
or should I ship patched libsdl binary with my applications?
I think standard practice is to have a resize handler that calls necessary
functions to reset glContext (including rebuilding textures). From what I
understand it’s not a bug, just a side effect of the GL context being
trashed after a window resize.
JohnOn Thu, Oct 7, 2010 at 11:21 PM, Xecutor <konstantin.stupnik at gmail.com>wrote:
Hello there.
Right now I’m trying to make a small library to be used in utility
applications with fancy UI and little games.
I’m making it using OpenGL on top of SDL.
On windows there are no problems with resizable window.
I’m just updating viewport and it works fine.
On mac os x it’s broken.
When I resize window, picture is moved in some random way, new space is
flickering with garbage and updating viewport do not help at all.
After digging for some time in SDL sources and various OpenGL samples for
mac os x,
I’ve found out that after window resize you need to call ‘update’ method on
opengl context.
As a quick hack I’ve added:
Code:
[ gl_context update];
to setFrame method at src/video/quartz/SDL_QuartzWindow.m:129
and it seems to fix the problem.
Probably it is valid solution.
I’ve heard that 1.2 was frozen… Is there a chance that fixed version will
come out,
or should I ship patched libsdl binary with my applications?
I think standard practice is to have a resize handler that calls necessary
functions to reset glContext (including rebuilding textures). From what I
understand it’s not a bug, just a side effect of the GL context being
trashed after a window resize.
Indeed, the context is remade. Textures, and I’m fairly sure display lists
are among the major things affected.
I’ve always been annoyed by this. Are there plans to fix it in future
versions of SDL?
IanOn Sun, Oct 10, 2010 at 4:17 PM, John Magnotti <john.magnotti at gmail.com>wrote:
VittorioOn Mon, Oct 11, 2010 at 12:43 AM, Ian Mallett wrote:
On Sun, Oct 10, 2010 at 4:17 PM, John Magnotti <john.magnotti at gmail.com> wrote:
My info on this may be out of date, but…
I think standard practice is to have a resize handler that calls necessary
functions to reset glContext (including rebuilding textures). From what I
understand it’s not a bug, just a side effect of the GL context being
trashed after a window resize.
Indeed, the context is remade.? Textures, and I’m fairly sure display lists
are among the major things affected.
I’ve always been annoyed by this.? Are there plans to fix it in future
versions of SDL?
Why would resizing window ruing opengl context?
It is not.
As I said earlier, with glcontext update it works just fine.
And it works just fine without any fixes on windows and linux.
I’m not calling setvideomode after resize.
There is no need to do this.
The link is about generic sdl functions. Not about opengl.
Xecutor – any idea how to fix this same problem in SDL 1.3? (The source code is quite different, and I can’t find where to do an OpenGL context update.)
Because the accessors are rebound. It’s complicated, and I shan’t presume
great knowledge about exactly why this happens. It is true that (sometimes)
the data remains valid, just as (sometimes) overwriting the bounds of an
array will be perfectly harmless.
The fact remains that problems can, and often do occur. I have experienced
this effect first hand, where the color channels of textures get changed or
deleted, and display lists throw vertex garbage. There’s a possibility you
won’t get such problems, but assuming they won’t happen is just wrong.
Some things that should remain valid are the viewport coordinates, the
context’s state (enable/disable). Bound objects might stay valid too, but
I’d have to check. So, reinitializing your renderer is not necessary.
Reloading your content is. I’ve experienced these problems on all three
major platforms.
It is not.
As I said earlier, with glcontext update it works just fine.
And it works just fine without any fixes on windows and linux.
I’m not calling setvideomode after resize.
There is no need to do this.
The link is about generic sdl functions. Not about opengl.
IanOn Mon, Oct 11, 2010 at 11:10 PM, Xecutor <konstantin.stupnik at gmail.com>wrote:
I have a similar issue with DOSBox-X and SDL2 on Mac OS X.
Resizing the window works OK for minor changes but beyond that (or going fullscreen, or maximizing) the OpenGL texture DOSBox-X uses to present the DOS display becomes garbled as if it’s not reading the correct bytes per row.
The garbling seems to happen at the call to glTexSubImage2D where it seems the function is using the logical width of the window rather than the width actually passed by DOSBox-X when transferring the in-memory render to the texture.
This issue does not occur with the SDL1 build.
DOSBox-X destroys and recreates the OpenGL context (and makes it current) when reinitializing the window on resize.