Re: [Chromium-dev] context type: UNDECIDED vs. CHROMIUM vs. NATIVE

[Brian P. <bri...@tu...>]

ma...@co... wrote:
> Brian,
> 
> Thanks for the explanation - that's very helpful.
> 
> 
>>The only time a context should be in the UNDECIDED state is when it's
>>been created, but has never been made current.  Perhaps the WGL code
>>is missing an assignment to set the context's type in wglMakeCurrent.
> 
> 
> What if it's never made current!?
> 
> Apparently, although it may be "wrong", what many (or at least 2) "real world"
> apps do is create a context, check some capabilities, and if it's not up to
> snuff, the context is deleted, without ever being made current.

What capabilities would be queried, and how (without making current)?

In GLX world, glXQueryContext() let's you query 3 things, like screen 
number and fbconfig.

In order to call glGetInteger/Float/Etc() you _must_ have a current 
rendering context.


> So, stubDestroyContext gets the context and does nothing to it, since the
> context type is UNDECIDED, and as a result the window stays up...
> 
> **So, what should stubDestroyContext do when the type is UNDECIDED?**

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?

Remember, windows and rendering contexts are very different things.

A problem in Chromium is we can never directly detect when a window is 
destroyed (with XDestroyWindow() or the Windows equivalent).  The best 
we can do is occasionally test window handles to see if they're still 
valid and delete the corresponding Cr data structure when we find 
invalid handles.  There's some such garbage collection code in the 
fake for GLX but I think it's currently disabled.

-Brian