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

[email protected] wrote:
> Hi all,
> 
> Could someone clarify the intent of the three different Context types:
> UNDECIDED, CHROMIUM, and NATIVE.
> 
> I'm running into a situation where contexts (i.e. windows) aren't being
> deleted, because their type is UNDECIDED.
> 
> The function stubDeleteContext in opengl_stub/context.c only takes action if
> the type is NATIVE or CHROMIUM, so contexts that are created under windows
> (wgl.c:wglCreateContext_prox) never get deleted.
> 
> 
> The result is that apps which create contexts just for the sake of querying
> capabilities end up spawning tens or hundreds of windows.

Chromium allows for some windows to be rendered with ordinary OpenGL 
and others with Chromium.  For example, some apps create one large 3D 
visualization window and some number of smaller widget-type windows. 
You many only want the large window to be rendered with Cr (on your 
tiled display perhaps).

When glXCreateContext is called we can't know at that time whether 
it'll be used for native rendering or Cr rendering, so it's marked as 
undecided.

Later, when the context is bound for the first time with 
glXMakeCurrent we can determine if it's a native or Cr context.  This 
is typically done by looking at the specified window's size or title 
string.  There's various app node config options for that.

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.

-Brian


-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click