PDA

View Full Version : Can't Change Viewport Size on XP, OpenGL 1.1?



NoelC
06-17-2010, 08:34 AM
I'm working on an app that renders OpenGL in a window. The dialog for the app, and the OpenGL-managed window within, is resizeable.

Upon window size change I am doing the classic commands listed in all the documentation for resetting the viewport size, and this works on most systems - but it simply isn't working on Windows XP 32 bit (SP3) with software OpenGL (1.1). Instead, the OpenGL viewport just remains at the size set when OpenGL was initialized, just after window creation.

// reset the viewport to the new dimensions
glViewport(0, 0, ProxyClientWidth, ProxyClientHeight);

// select the projection matrix and clear it out
glMatrixMode(GL_PROJECTION);
glLoadIdentity();

// Set up OpenGL for 2d rendering
gluOrtho2D(0, ProxyClientWidth, ProxyClientHeight, 0);

// Further drawing needs GL to be in model mode.
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();


Based on some experimentation, the problem seems to be tied to using the PFD_DOUBLEBUFFER flag in the pixel format descriptor used to SetPixelFormat(). If I remove PFD_DOUBLEBUFFER, the buffer size does change, but of course the display is noisy as it's being rendered on screen instead of behind the scenes.

Is this a known issue with older XP systems? Is there a workaround?

Thanks.

-Noel Carboni

strattonbrazil
06-17-2010, 01:17 PM
Is this in your reshape function? If you query the viewport size from the display function, what do you get back?

mhagain
06-17-2010, 01:26 PM
Have you got PFD_SUPPORT_GDI also? According to MSDN that and PFD_DOUBLEBUFFER are mutually exclusive.

sammie381
06-17-2010, 03:35 PM
I'm working on an app that renders OpenGL in a window. The dialog for the app, and the OpenGL-managed window within, is resizeable.

Upon window size change I am doing the classic commands listed in all the documentation for resetting the viewport size, and this works on most systems - but it simply isn't working on Windows XP 32 bit (SP3) with software OpenGL (1.1). Instead, the OpenGL viewport just remains at the size set when OpenGL was initialized, just after window creation.


I think you need to provide more information about the GUI framework you're using.
MFC? Or some open source toolkit?

NoelC
06-18-2010, 01:20 PM
Hi guys, thanks for your responses.

The code listed above happens when the window size is changing. It's not executed in the UI thread, however; we have a separate rendering thread.

After the above code executes, a glGetIntegerv(GL_VIEWPORT, ViewportExtent) call reports the resized coordinates as though the viewport was correctly resized. The display, however, is truncated. See this image, which is a result of resizing the dialog up from a smaller size in which the display window was tall and thin, smaller in both dimensions than the current window:

http://images.ProDigitalSoftware.com/TruncatedDisplay.jpg

Note that the lower left corner of the portion of the OpenGL display showing is not anchored at the lower left corner of the display area, which is just above the little [-] button. The image should extend over to the scroll bars, and have a black 1 pixel line painted all the way around it.

PFD_SUPPORT_GUI is not in use. We need the double buffering, and we do all window display in this window via OpenGL.

In answer to your GUI framework question, sammie381: MFC is not in use - we're using Microsoft Visual Studio 2008, building a VC++ project with opengl32.lib and glu32.lib from the Windows SDK 7.0.

Thanks for any insight you can share.

-Noel

NoelC
06-19-2010, 01:03 PM
Bah, I found it. It's a Windows bug with the GDI Generic 1.1 implementation of OpenGL.

http://support.microsoft.com/kb/q272222/

If it just affected older systems that would be something I could handle, but noooooooooo.... It happens over a modern RDP connection too (in which guess what? OpenGL is the GDI Generic 1.1 implementation).

So it's off to render to bitmaps under some conditions, and to the screen in others. Sigh.

No wonder even well-funded companies like Adobe still have so much trouble with OpenGL.

-Noel