chromium-dev

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

[<ma...@co...>]

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.


Thanks as always,
Jon Marbach

Univesity of Colorado at Boulder
BP Center for Visualization

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

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

ma...@co... 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

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

[<ma...@co...>]

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.

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?**


Thanks,
Jon

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

[Greg H. <hu...@gm...>]

Ah yes, this seems familiar.  I definitely made some changes to the  
way that contexts were created/deleted on Windows.  This had to do  
with the fact that contexts for pbuffers are created with a separate  
function on Windows which was only partially supported in Chromium  
(it sort of worked but didn't add the context to the hashtable  
because there was no "window info" when the special  
wglMakeContextCurrent function was called).

On May 25, 2005, at 6:05 PM, 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.
>
> 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?**
>
>
> Thanks,
> Jon
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>
>

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

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

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

[<ma...@co...>]

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.

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...

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.

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!

Jon

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

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

ma...@co... 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

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

[Greg H. <hu...@gm...>]

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.

On May 25, 2005, at 5:19 PM, ma...@co... 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.
>
>
> Thanks as always,
> Jon Marbach
>
> Univesity of Colorado at Boulder
> BP Center for Visualization
>
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>
>

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

[Chromium-dev] PixelFormat issues under Win32

[<ma...@co...>]

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 <hu...@gm...>:

> 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.
>

[Chromium-dev] Re: PixelFormat issues under Win32

[Greg H. <hu...@gm...>]

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, ma...@co... 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 <hu...@gm...>:
>
>
>> 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/

[Chromium-dev] Re: PixelFormat issues under Win32

[<ma...@co...>]

Greg,

> Glad to hear you're on the case.

Thanks!

I know there currently isn't a huge demand for Chromium on Windows, but I
think that could be a chicken and egg issue.

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

Not true in the case of professional CAD, Engineering, and Design apps,
and our client is interested in these!

But that's OK - they wouldn't have hired our research center if it was a piece
of cake ;)

Jon