Re: context type: UNDECIDED vs. CHROMIUM vs. NATIVE

[email protected] wrote:
> Brian,
> 
> Let me first say that I think Chromium is great! And I'm so glad it supports
> Win32 at all! So thank you everyone who's got Chromium on Win32 this far.
> 
> I'm happy to be working on expanding the robustness of Chromium on Win32.
> 
> 
>>What capabilities would be queried, and how (without making current)?
> 
> 
> If I only knew! (I think these apps assume that the last created context is
> automatically made current.)
> 
> Literally, one of the apps names its WindowClass "query". (WindowClass is a
> Win32 thing - it's an internal window name.) Another app is naming the window
> classes "OpenGL Info Window". It seems pretty clear that these apps are
> creating hidden windows, and creating contexts for them, in the hopes of
> discovering some properties of the OpenGL driver. While it may not be
> the "right" way to do it, they do it! And I don't think I have enough pull to
> convince them to change their source code.

I've seen this kind of thing before too.  Sometime you just have to 
bend the specs a bit to make legacy apps work.


> The lovely part of all this is you have to guess what the 3rd party app is
> doing - it's like detective work... It seems as though the apps I'm testing
> create a context, then do a GetPixelFormat to see if the context was created
> according to spec, i.e., with the PixelFormat that was requested...

The combination of app node hosting a print SPU followed by a render 
SPU can be useful for figuring out what the app's doing.


> In short, some apps are very picky about what pixelFormats are available, and
> I'm working on expanding the WGL implementation to make those picky apps happy.
> 
> 
>>I'm still not 100% clear on whether the issue is with rendering
>>contexts or with windows.  You mentioned that the window stays up.
>>Are there many rendering contexts and one window, or many rendering
>>contexts and many windows?
> 
> 
> I may be speaking too soon here, but it looks like Chromium, at least in "stand
> alone" mode, creates a new render spu (and a new window for the spu) every time
> stubCreateContext is called.

There's only one render SPU, but it will create new contexts and 
windows as needed.  Generally, a new context is created when 
wgl/glXCreateContext() is called.  Since windows are created outside 
of Cr with win32 or Xlib calls, we don't typically create a Cr window 
until wgl/glXMakeCurrent is called.  That's the first time Cr will see 
the native window handle.


> But before I blah blah blah about all this any further, I'll be investigating
> this further this afternoon, so I'll get back to you on it with clearer info.
> 
> Thanks for the help and advice!

OK.

-Brian


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005