While looking @ trimming down my initialisation code I've noticed ChoosePixelFormat blocks for between 0.5 & 2 seconds when called.

Could anyone offer any advice on selecting pixel format manually, or skipping non-essential (internal) lookups that may be causing the pause?

ps: I like waffles

[Edited by - ProPuke on July 2, 2010 6:48:15 PM]

Quote:Original post by ProPuke
While looking @ trimming down my initialisation code I've noticed ChoosePixelFormat blocks for between 0.5 & 2 seconds when called.

Could anyone offer any advice on selecting pixel format manually, or skipping non-essential (internal) lookups that may be causing the pause?

ps: I like waffles

There are two variants of ChoosePixelFormat: one in gdi32.dll and one in opengl32.dll (the latter is called wglChoosePixelFormat). If one takes too long, try the other and the delay will disappear.

PS: what kind of waffles do you like?

Try to set up your PFD so that it more closely matches the capabilities of most common hardware; this will give it a better chance of finding a matching format more quickly.

Example: you might be asking for a 32-bit depth buffer. There is no such thing as a 32-bit depth buffer on the vast majority of consumer hardware, a depth buffer is either 24-bit (the remaining 8 may or may not be used for stencil) or 16-bit. So now ChoosePixelFormat has to scan through all of the available formats, determine that what you asked for is unavailable, then work out how best to gracefully degrade and find one that is supported. Asking for a 24-bit depth buffer would avoid this.

This is just an example, and it may not be exactly what you have, but it is one I've seen very often.

Thanks for the responses so far guys.

Sources online seem to indicate wglChoosePixelFormat is a system function used internally by ChoosePixelFormat & should not be called directly. (t may be unsafe to do so, or not always return reliable results)

Thanks, too, mhagain, but changing the pixel format requirements don't seem to make any difference to the time from here, either (although it was a nice suggestion)

I'm gonna have a look through Microsoft's GLEnum & see if I can narrow down the cause & step around it (I don't see why querying pixel formats should take so long, I suspect there may be some "virtual" devices causing foul-play)

But once again - any thoughts from people who may have experience with this would be very much appreciated. Thank you.


ps: I'm not sure I really have a specific preference. I'm a simple kinda guy, maybe I need to broaden my waffling horizons

Brief tests seem to indicate that (@ least in windows 7 under the latest nvidia drivers) all information is fetched & cached upon the first call to any *PixelFormat function.
No further substantial delays occur after this first call.
This, however, means that manually enumerating through the modes is no faster (again, the first call blocks [for several hundred or thousand ms], & later calls execute "fast")

I guess I can move detection across to a parallel thread on startup (so it does not stall non-dependant elements) & cache the result for systems that do not; but I'd still like to alleviate the delay all together, if any one has any ideas?

Oh well, thanks anyway guys