I'm testing supporting multiple resolutions in an application using SDL2 with OpenGL. To create my "letterbox" functionality I set my glViewport to an appropriate value and everything works perfectly.
However, if I create my window with the SDL_WINDOW_ALLOW_HIGHDPI flag set, whenever I move my window (after receiving the SDL_WINDOWEVENT_MOVED event) SDL modifies the viewport to the full size of the window, which can be verified by calling SDL_GL_GetDrawableSize during the event.
If I do not set SDL_WINDOW_ALLOW_HIGHDPI when creating the window, the viewport is not reset. I do believe this to be a bug, but cannot find anything through the SDL bugzilla so I thought to ask if anyone has seen similar behavior.
You may need to have a retina MacBook Pro to experience this behavior.
Just do what you should be doing anyway: Always re-/set the viewport at the beginning of drawing each frame. As soon as you want to implement a HUD, use framebuffer objects or similar things you'll have to set the viewport (several times) for drawing each frame.
Related
On screen 0, I have the mainWindow with two QOpenGLWidgets running video. On screen 1, I have another QOpenGLWidget in fullscreen mode running video. The screen 0 is a preview of what the user is seeing on the second display, which is a pair of glasses. Everything was working fine, until I added the fullscreen widget. Now only the fullscreen widget updates and the other two only update if I cause the window to repaint, e.g. moving the window.
I am a noob when it comes to opengl, but the two widgets, in the mainWindow are running together fine. So I don't believe it is the code. Is this a limitation of opengl? Qt? me?
I am using Qt5.4.
I missed an error in the console due to a lot of noise.
Requires a valid current OpenGL context.
Texture has not been destroyed
A quick search and I got my answer. I wasn't calling makeCurrent() when I was updating the texture with the next frame.
I am trying to change the size of the window of my app with:
mysurface = SDL_SetVideoMode(width, height, 32, SDL_OPENGL);
Although I am using vsync swapbuffers (in driver xorg-video-ati), I can see flickering when the window size changes (I guess one or more black frames):
void Video::draw()
{
if (videoChanged){
mysurface = SDL_SetVideoMode(width, height, 32, SDL_OPENGL);
scene->init(); //Update glFrustum & glViewPort
}
scene->draw();
SDL_GL_SwapBuffers();
}
So please, someone knows, if...
The SDL_SetVideoMode is not vsync'ed as is SDL_GL_SwapBuffers()?
Or is it destroying the window and creating another and the buffer is black in meantime?
Someone knows a working code to do this? Maybe in freeglut?
In SDL-1 when you're using a windowed video mode the window is completely torn down and a new one created when changing the video mode. Of course there's some undefined data inbetween, which is perceived as flicker. This issue has been addressed in SDL-2. Either use that or use a different OpenGL framework, that resizes windows without gong a full window recreation.
If you're using a FULLSCREEN video mode then something different happens additionally:
A change of the video mode actually changes the video signal timings going from the graphics card to the display. After such a change the display has to find synchronization with the new settings and that takes some time. This of course comes with some flickering as the display may try to display a frame of different timings with the old settings until it detects that those no longer match. It's a physical effect and there's nothing you can do in software to fix this, other than not changing the video mode at all.
I've written an OpenGL application in Linux through GLX. It uses double buffering with glXSwapBuffers and Sync to VBlank set via NVIDIA X Server Settings. I'm using Compiz and have smooth moving of windows and no tearing (Sync to VBlank enabled in Compiz settings).
But when I
Try to move or resize the OpenGL window or
Move other windows through the area occupied by the OpenGL window
the system stutters and freezes for 3-4 seconds. Moving other
windows outside the area occupied by the OpenGL window is smooth as always.
Moreover the problem only arises if the OpenGL application is in the
loop of producing frames of animation therefore swapping the buffers.
If the content is static and the application is not swapping the buffers there are no problems,moving the various windows is smooth.
Could be a synchronization issue between my application and Compiz?
I don't know if it's still in the same shape as a few years ago, but…
Your description matches very well a Compiz SNAFU. Every window resize triggers the recreation of a texture that will receive the window contents. Texture creation is a costly operation and hence should be avoided. Unfortunately the Compiz developers don't seems the brightest ones, because they did not realize there's an obvious solution to this problem: Windows in X11 can be reparented without much cost (every Window manager does this several times), it's called stacking. Compiz is a window manager.
So why doesn't Compiz keep a desktop sized window around into which it reparents those windows that are about to be resized, gets its constant sized window texture from there and after finishing the resize operation reparents the window into its decoration frame?
I don't know why this is the case. Anyway, some things Compiz does are not very smart.
If you want to fix this, well: Compiz is open source and I just described what to do.
I have an app that mixes OpenGL with Motif. The big main window that has OpenGL in it redraws fine. But, the sub windows sitting on top of it all go black. Specifically, just the parts of those subwindows that are right on top of the main window. Those subwindows all have just Motif code in them (except for one).
The app doesn't freeze up or dump core. Data is still flowing, and as text fields, etcetera of various subwindows get updated, those parts redraw. Dragging windows across each other or minimizing/unminimizing also trigger redraws. The timing of the "blackout" is random. I run the same 1-hour dataset every time and sometimes the blackout happens 5 minutes into the run and sometimes 30 minutes in, etc.
I went through the process of turning off sections of code until the problem stopped. Narrowed it down more and more and found it had to do with the use of the depth buffer. In other words, when I comment out the glEnable(GL_ENABLE_DEPTH_TEST), the problem goes away. So the problem seems to have something do with the use of the depth buffer.
As far as I can tell, the depth buffer is being cleared before redrawing is done, as it should. There's if-statements wrapped around the glClear calls, so I put messages in there and confirmed that the glClear of the depth buffer is indeed happening even when the blackout happens. Also, glGetError didn't return anything.
UPDATE 6/30/2014
Looks like there's still at least one person looking at this (thanks, UltraJoe). If I remember correctly, it turned out that it was sometimes swapping buffers without first defining the back buffer and drawing anything to it. It wasn't obvious to me before because it's such a long routine. There were some other minor things I had to clean-up, but I think that was the main cause.
How did you create the OpenGL window/context. Did you just get the X11 Window handle of your Motif main window and created the OpenGL context on that one? Or did you create a own subwindow within that Motif window for OpenGL?
You should not use any window managed by a toolkit directly, unless this was some widget for exclusive OpenGL use. The reason is, that most toolkits don't create a own sub-window for each an every element and also reuse parts of their graphics resources.
Thus you should create a own sub-window for OpenGL, and maybe a further subwindow using glXCreateWindow as well.
This is an old question, I know, but the answer may help someone else.
This sounds like you're selecting a bad visual for your OpenGL window, or you're creating a new colormap that's overriding the default. If at all possible, choose a DirectColor 24-plane visual for everything in your application. DirectColor visuals use read-only color cells, but 24 planes will allow every supported color to be available to every window without having to overwrite color cells.
We recently ported Bitfighter from GLUT to SDL. There were numerous benefits to doing this, but a few drawbacks as well, especially in the area of window management.
Bitfighter runs in a fixed-aspect-ratio window (800x600 pixels). Users can make their window any size they want, but we capture the resize event and make adjustments to the requested size to ensure the window keeps the correct proportions (using SDL_SetVideoMode).
(The following problem applies to Windows, but has not yet been tested on other platforms. What I describe below refers specifically to Windows, though I am looking for a platform-independent solution.)
Ordinarily, this works great, except when users maximze their window by double clicking on the title bar or using the maximize button. In that case, the window resize event is called with the a window size approximating the screen size (minus some pixels for window ornamentation). Unfortunately, when the window is maximized, SDL_SetVideoMode has no effect (unlike GLUT which was able to resize a maximized window). Furthermore, subsequent calls to SDL_GetVideoInfo report the size we requested, not the actual current size of the window, so it is hard to tell if the attempted resizing worked.
I am looking for a platform independent way to do any of the following (in descending order of preference):
Resize a window after it's been maximized
Detect when a window has been maximized so that, knowing I can't resize it, I can at least adjust the video to be centered
Prevent a window from being maximized (block double clicks on window title bar, use of the maximize button, and dragging the window to the top of the screen)
Bitfighter is written in C++, and we're using the latest official release of SDL.
Migrate to SDL 2.0 (which it seems you already have)
SDL 2.0 provides a better API to window management (it actually provides one). While there are still many bugs in Windows management in SDL 2.0 (especially on the Linux side), it has vastly improved since the 1.2 days.
I assume, that you use OpenGL with SDL, because you used GLUT before. I don't know any solutions for that problem, exept point 2. If you want the Video to have a specific size, just leave the SDL-Window like it is, and call
glViewport(0, 0, width, height);
with the right size with the right proportions.
With that solutions you will still have a black border in your window, but It only shows as much, as you want. (with the first 2 arguments you can also set the position of the Viewport in the window ;) )