PDA

View Full Version : Pixel formats problems (MX 440)



muvee
08-26-2008, 03:46 AM
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 (http://www.muvee.com/en/products/reveal/).

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.

skalogryz
08-26-2008, 05:04 AM
do you create and choose gl context, before glGetString call?

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

muvee
08-26-2008, 05:11 AM
do you create and choose gl context, before glGetString call?

-- Yes, I call glGetString after I create gl context.

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

--I use nvidia drivers.



Thanks for your reply, skalogryz.

skalogryz
08-26-2008, 05:55 AM
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?

muvee
08-26-2008, 10:58 PM
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?

--No. In both runs,
ChoosePixelFormat() returns non-zero results (10 for run-A and 7 for run-B);
SetPixelFormat() returns true;
wglCreateContext() returns not NULL rc;
wglMakeCurrent() returns true;

So can I say there are no errors in those 4 functions?

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

--If I do this, same result as above, except that the original 0x00000500 'invalid enumerant' error becomes 0x00000502 "GL_INVALID_OPERATION".
By the way, the error is for some glGenTextures() before rendering starts, for run-B of course.


Thanks for your inputs..

skalogryz
08-27-2008, 01:54 AM
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?

muvee
08-27-2008, 02:00 AM
It is strange.

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

Small tests always succeeds on that machine.

Lastly, run A & B are independent.

skalogryz
08-27-2008, 02:11 AM
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.

muvee
09-03-2008, 09:18 PM
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? :)

tamlin
09-04-2008, 10:34 AM
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.

muvee
09-05-2008, 03:32 AM
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!

yooyo
09-05-2008, 06:47 AM
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.

tamlin
09-06-2008, 12:56 PM
When you say wrong (H)DC, what do you mean?
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.

muvee
09-09-2008, 12:33 AM
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.

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.