Re: PixelFormat issues under Win32

Sounds good.  I have no doubt that the pixel format code is highly  
non-robust on Windows, as:

1) most applications don't care, and
2) most applications run on Linux

Glad to hear you're on the case.

On May 25, 2005, at 7:21 PM, [email protected] wrote:

> Greg,
>
> In general, here's what I'm trying to do to get around various  
> PixelFormat
> issues:
>
> 1) I'm trying to add more than one pixel format option in wgl.c
>
> At least one app we've run needs to see a GENERIC_FORMAT as a  
> fallback option.
> Also, it appears that some apps just NEED to fish through a list of  
> available
> PixelFormats, try them on, and then go with one of them.
>
> 2) That means I've got to add an extra hashtable into stub that  
> tracks pixel
> formats for HDCs.
>
> Apparently apps don't like it if they set the pixel format to n,  
> and then get
> back a pixel format of 1!
>
>
> I'm just testing some of this out as we speak, so I'll get back to you
> tomorrow with more results.
>
> Thanks,
> Jon Marbach
>
> BP Center for Visualization
> www.bpvizcenter.com
>
>
>
>
>
> Quoting Greg Humphreys <[email protected]>:
>
>
>> I ran into some issues with these three types when I was trying to
>> run Brook programs through Chromium on Windows for a paper push
>> recently.  Unfortunately I was in such paper writing mode I don't
>> remember what I did.  It had something to do with the fact that
>> Chromium returns "Humper" as the GL_VENDOR if you do a glGetString()
>> before any context is actually created (which is supposed to work).
>>
>> I suspect that the pixel format bug is a serious one and was
>> affecting our efforts to run FarCry through Chromium for that paper.
>>
>

--
Greg Humphreys, Assistant Professor
Department of Computer Science, University of Virginia
http://www.cs.virginia.edu/~humper/