Pixel formats problems (MX 440)

Hi all,

I ran into an interesting problem with VC++/OpenGL programming (UI done in WPF).

The program I’m talking about is muvee Reveal (muvee | Video Editing Software for Drones, Action Cams & 360 Video).

And here’s the problem. In the same testing machine (XP with GeForce MX 440), two different pixel formats are returned before creating rendering contexts in two individual program runs. The only difference between the two runs is that a picture is added in the UI in run-B but not in run-A, from which I cannot figure out any direct cause of the issue.

The result of the above is that correct renderer is recognized and scene rendering succeeds in run-A. However, in run-B “GDI Generic” is reported from glGetString(GL_RENDERER) and OpenGL error 0x00000500 ‘invalid enumerant’ is raised before rendering starts.

I’d like to have either questions below answered.

  1. Under what condition could ChoosePixelFormat(HDC, PIXELFORMATDESCRIPTOR) return different results from the same machine, provided both parameter passed in are the same?

  2. If there’s any chance that the HDCs passed into ChoosePixelFormat() are different during the two runs, how can I tell?
    The window creation code is the same for both runs and I’ve dumped GWL_EXSTYLE and GWL_STYLE just before the line of ChoosePixelFormat(). They are the same in both runs.

If this is a driver-related issue, could someone please confirm. Thanks!

More details are available upon request.

do you create and choose gl context, before glGetString call?

do you use MX 440 drivers, provided by NVidia, or is it Microsoft drivers?

Thanks for your reply, skalogryz.

I guess, that in the run-B, pixel format is chosen incorrectly. This might be the reason for the B context not to be created at all! and so, call to the glGetString returns error.

Does ChoosePixelFormat, SetPixelFormat, wglCreateContext and wglMakeCurrent return with no error in run-B?

Upd: is it possible, to force setting pixel format in run-B, to the same as in run-A?

Thanks for your inputs…

it’s really strange.
Could you post your code here? (or publish somethere for download?)
or if it’s to heavy, how about creating a small test, that would initialize gl context gets and prints GL_RENDERER string.

By the way, is there a difference, if you run B prior to A?

It is strange.

Code is heavy. And it involves WPF && c#.

Small tests always succeeds on that machine.

Lastly, run A & B are independent.

HDC might differ, if some code changes dc resources (bitmaps, brushes… etc). It might be caused by adding picture. And previosly aquired DC, might be invalid.

The best thing you can do, is getting HDC right before calling ChoosePixelFormat.

Just want to share with you guys some updates on this issue.

We’ve narrowed down it to an customized file-open-dialog that we use to pre-process the picture inputs using GDIPlus.
If we disable that dialog, the problem disappears. Any clue/experience on this? :slight_smile:

The most obvious answer is wrong (H)DC. Try tracing what GetObjectType (I think the function is named) returns on the runs that works vs. fails.

Thanks for your inputs, tamlin .

So I add
printf(“Before choosepixelformat, hdc type = %08x”, GetObjectType(hDC) );

before I call
nPixelFormat = ChoosePixelFormat( hDC, &pfd );

In both runs, it printed “00000003”, which means OBJ_DC. So I suppose the type of HDC is correct.

Again, my original question:
2) If there’s any chance that the HDCs passed into ChoosePixelFormat() are different during the two runs, how can I tell?
The window creation code is the same for both runs and I’ve dumped GWL_EXSTYLE and GWL_STYLE just before the line of ChoosePixelFormat(). They are the same in both runs.

When you say wrong (H)DC, what do you mean? How do I tell if an hDC is wrong? Thanks!

Whats happens in this custom fileopen dialog? Is there any advanced stuff, like creating another RC or D3D device for file preview, or such? You said that it use GDI+ to do something. Maybe you didnt cleanup GDI+ stuff correctly.

From MSDN:

An OpenGL window has its own pixel format. Because of this, only device contexts retrieved for the client area of an OpenGL window are allowed to draw into the window. As a result, an OpenGL window should be created with the WS_CLIPCHILDREN and WS_CLIPSIBLINGS styles. Additionally, the window class attribute should not include the CS_PARENTDC style.

Even more… you cant call SetPixelFormat more tha once per DC. If your custom fileopen dialog includes CS_PARENTDC and create temporary RC then this could cause a problem.

I was thinking if the dialog perhaps created a MEMDC and didn’t restore properly after itself so that you might have tried to use a MEMDC for GL.

Thanks for your input. We learned the lesson not to call SetPixelFormat more than once per DC several months back. Currently our UI team’s looking into this issue. Will update here once they found something.