PDA

View Full Version : wglCreateContext and ERROR_INSUFFICIENT_BUFFER



SoonerWolf
06-22-2012, 01:40 PM
I have an application that uses three separate OpenGL contexts embedded in Windows forms. The first two are of identical size and initialize and run normally. The third is smaller and I cannot create a context on Windows XP SP3, but works fine in Windows 7.

The hardware for both Win7 and WinXP is a Parallels 7 Virtual machine with a MacOS host. I have allocated 256 MB of Video memory and 2GB of RAM.

Here's the GL context creation method I use for all contexts:


PIXELFORMATDESCRIPTOR pfd = {
sizeof(PIXELFORMATDESCRIPTOR), // size of this pfd
1, // version number
PFD_DRAW_TO_WINDOW | // support window
PFD_SUPPORT_OPENGL | // support OpenGL
PFD_DOUBLEBUFFER, // double buffered
PFD_TYPE_RGBA, // RGBA type
24, // 24-bit color depth
0, 0, 0, 0, 0, 0, // color bits ignored
0, // no alpha buffer
0, // shift bit ignored
0, // no accumulation buffer
0, 0, 0, 0, // accum bits ignored
32, // 32-bit z-buffer
0, // no stencil buffer
0, // no auxiliary buffer
PFD_MAIN_PLANE, // main layer
0, // reserved
0, 0, 0 // layer masks ignored
};


GLuint pixelFormat = ::ChoosePixelFormat(mDc, &pfd);
if (!pixelFormat)
{
CxDebugLastError();
CxThrow(CxErrorOpenGL);
}

bool validPixelFormat = ::SetPixelFormat(mDc, pixelFormat, &pfd);
if (!validPixelFormat)
{
CxDebugLastError();
CxThrow(CxErrorOpenGL);
}

mContext = ::wglCreateContext(mDc);
if (!mContext)
{
CxDebugLastError();
CxThrow(CxErrorOpenGL);
}


mDc is fetched from an HWND passed into the method, and is valid.

mContext is a HGLRC stored in the class. It has the address of 0x00010002 after the call to wglCreateContext for the aforementioned WinXP issue, thus the "if (!mContext)" fails and doesn't report an error. I had to move "CxDebugLastError()" outside the if-check to see that I was getting ERROR_INSUFFICIENT_BUFFER.

1) Why is this failing on Windows XP SP3, but working fine on Windows 7?

2) Why does wglCreateContext not return NULL when it fails in this case as the documentation states it should?

p.s. - This did not occur until we started using Visual Studio 2010 and Windows forms. Previously we created the windows programmatically using a MacOS NIB file for the form design. Could there be a Windows form setting that might be causing/might fix this issue?

mhagain
06-22-2012, 02:46 PM
ERROR_INSUFFICIENT_BUFFER is a generic Win32 API error code that is thrown by an API call that takes a variable-length output buffer as an arg (such as RegQueryValueEx). My best guess here is that Windows Forms is making Win32 API calls behind the scenes, and you've encountered a bug in the underlying layer on your XP machine.

For your question 2, and I'm guessing again, but my theory is that the error is causing another internal function (that either successfully completes the context setup, or else sets your context to NULL on failure) to early-out before it can do the right thing.

The most likely cause is a driver bug on the XP machine, as XP and 7 have different driver models - so even with the very same hardware this is possible. Ultimately the wglCreateContext call will be performed and completed within the driver (not the OS) so a driver update - if your VM software has one available - is the most likely solution.

The next steps after that would be a Windows update (if the bug is happening within Windows itself it may very well have since been patched) or moving to a different version of the .NET framework.

Otherwise, and if you are targetting Windows as a platform, I would highly recommend running natively on a Windows box. VMs are great for testing up to a point, but the test setup you're using is one that's not representative of what your customers will have.

SoonerWolf
06-22-2012, 03:35 PM
I've tested on a 2007-era MacBook Pro running WinXP natively (on boot camp) with Radeon 1600 and had no opengl contexts rendering, however it appeared data was there as our cursor-tracking was reporting data being plotted.

Other internal testers are reporting a variety of Windows XP issues as well, while our Windows 7 users are getting fairly consistent results.

If only our users were all using Windows Vista or 7.... :(