chromium-dev — For developers of the Chromium framework or SPU's

Re: [Chromium-dev] Bug in tilesortspu_context?

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

ma...@co... wrote:
> Hi all,
> 
> At the end of tilesortspu_context.c, the existing code in
> tilesortspu_DestroyContext looks like this:
> 
> /* Destroy the tilesort state context */
> crFree(contextInfo->server);
> crStateDestroyContext(contextInfo->State);
> crHashtableDelete(tilesort_spu.contextTable, ctx, crFree);
> 
> /* The default buffer */
> crPackSetBuffer( thread0->packer, &(thread->geometry_buffer) );
> 
> crDLMFreeContext(contextInfo->dlmContext);
> 
> -------
> 
> The problem is that, apparently, crHashtableDelete is deleting the data
> pointed to by contextInfo. (contextInfo is retrieved from the hashtable
> earlier in the function.)
> 
> So, a version that seems to work better for me (i.e. no crash on context
> deletion) is:
> 
> /* Destroy the tilesort state context */
> crFree(contextInfo->server);
> crStateDestroyContext(contextInfo->State);
> 
> /* The default buffer */
> crPackSetBuffer( thread0->packer, &(thread->geometry_buffer) );
> 
> crDLMFreeContext(contextInfo->dlmContext);
> 
> crHashtableDelete(tilesort_spu.contextTable, ctx, crFree);
> 
> ----

That looks like a good fix.  I'll check it in.

-Brian

[Chromium-dev] Bug in tilesortspu_context?

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

Hi all,

At the end of tilesortspu_context.c, the existing code in
tilesortspu_DestroyContext looks like this:

/* Destroy the tilesort state context */
crFree(contextInfo->server);
crStateDestroyContext(contextInfo->State);
crHashtableDelete(tilesort_spu.contextTable, ctx, crFree);

/* The default buffer */
crPackSetBuffer( thread0->packer, &(thread->geometry_buffer) );

crDLMFreeContext(contextInfo->dlmContext);

-------

The problem is that, apparently, crHashtableDelete is deleting the data
pointed to by contextInfo. (contextInfo is retrieved from the hashtable
earlier in the function.)

So, a version that seems to work better for me (i.e. no crash on context
deletion) is:

/* Destroy the tilesort state context */
crFree(contextInfo->server);
crStateDestroyContext(contextInfo->State);

/* The default buffer */
crPackSetBuffer( thread0->packer, &(thread->geometry_buffer) );

crDLMFreeContext(contextInfo->dlmContext);

crHashtableDelete(tilesort_spu.contextTable, ctx, crFree);

----

Jon

Re: [Chromium-dev] Render to App Window... On Windows?

[Sean A. <sea...@ll...>]

ma...@co... wrote:
> What would be a good name for an ENV variable to toggle "my" new
> feature.

I would suggest making it a server variable in the mothership python
configuration file rather than an environment variable.

-Sean

__
sea...@ll...
925-422-1648

Re: [Chromium-dev] Render to App Window... On Windows?

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

Mike,

You're right - that is an advantage of the render-to-app-window feature.

I think in general, if my changes get back into the tree, we'd just have to
make sure users understand the tradeoffs between one way and the other.

> It's still very useful for tiled display work however...

Probably the #1 use for Chromium right now... right?

Anyway, thanks for your input!

What would be a good name for an ENV variable to toggle "my" new feature.


Jon



Quoting mho...@gr...:

> I think you might be misunderstanding the purpose of render-to-app-window.
>  What you have built is effectively a "T" SPU.  Allowing the window to be
> drawn by the original app as well as feed the Chromium SPUs.
> render-to-app-window as currently written means that after the stream has
> gone through transformations, the render spu will use the original app
> window to render to instead of putting up it's own window.  For example,
> you might use Chromium to change the colors of vertices in the
> application, and instead of rendering to a separate window, you want to
> replace the original app's rendering.
>
> What you have made has actually been requested by many in the past.  The
> main issue with your approach is that it will show the app rendering prior
> to stream tranformations.  It's still very useful for tiled display work
> however...
>
> -Mike
>

Re: [Chromium-dev] Render to App Window... On Windows?

[<mho...@gr...>]

I think you might be misunderstanding the purpose of render-to-app-window.
 What you have built is effectively a "T" SPU.  Allowing the window to be
drawn by the original app as well as feed the Chromium SPUs. 
render-to-app-window as currently written means that after the stream has
gone through transformations, the render spu will use the original app
window to render to instead of putting up it's own window.  For example,
you might use Chromium to change the colors of vertices in the
application, and instead of rendering to a separate window, you want to
replace the original app's rendering.

What you have made has actually been requested by many in the past.  The
main issue with your approach is that it will show the app rendering prior
to stream tranformations.  It's still very useful for tiled display work
however...

-Mike

> Mike,
>
> Thanks for the suggestion, but I think that concept has led to the Windows
> render-to-app-window problem in the first place... I think the problem is
> that
> one processes can't render into another's Window (window id's might be
> process-
> specific ) I don't know for sure what the cause is, but the existing
> implementation definitely doesn't work!
>
> In the meantime, I went ahead with my plan and it looks like it works!
> (For
> single window apps anyway... and so far I've only tried city...)
>
> Having the stub itself double dispatch to the spus and the app window
> should
> be higer performance anyway, since you're not sending the calls off to
> another
> process, right?
>
> The only tricky part is handling which context is the current native
> context,
> but another half day and a hash table or two should settle that...
>
> Thanks,
> Jon
>
> ps. The IEEE Vis talk that you, Brian, et. al. put on has been super
> valuable.
> Thanks again for having done that! Will there be another this year?
>
>
> Jonathan Marbach
> BP Center for Visualization
> University of Colorado
>
>
> Quoting Mike Houston <mho...@gr...>:
>
>> The main issue on the windows side is someone figuring out how to pass
>> the gid(?) information around so Chromium can grab the window.  Under
>> *nix, this is pretty easy through X11.  I would suggest following along
>> the X11 path and see if something similar can be done on the Windows
>> path.
>>
>> -Mike
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> shotput
> a projector? How fast can you ride your desk chair down the office luge
> track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>

Re: [Chromium-dev] Render to App Window... On Windows?

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

Mike,

Thanks for the suggestion, but I think that concept has led to the Windows
render-to-app-window problem in the first place... I think the problem is that
one processes can't render into another's Window (window id's might be process-
specific ) I don't know for sure what the cause is, but the existing
implementation definitely doesn't work!

In the meantime, I went ahead with my plan and it looks like it works! (For
single window apps anyway... and so far I've only tried city...)

Having the stub itself double dispatch to the spus and the app window should
be higer performance anyway, since you're not sending the calls off to another
process, right?

The only tricky part is handling which context is the current native context,
but another half day and a hash table or two should settle that...

Thanks,
Jon

ps. The IEEE Vis talk that you, Brian, et. al. put on has been super valuable.
Thanks again for having done that! Will there be another this year?


Jonathan Marbach
BP Center for Visualization
University of Colorado


Quoting Mike Houston <mho...@gr...>:

> The main issue on the windows side is someone figuring out how to pass
> the gid(?) information around so Chromium can grab the window.  Under
> *nix, this is pretty easy through X11.  I would suggest following along
> the X11 path and see if something similar can be done on the Windows path.
>
> -Mike
>

Re: [Chromium-dev] Render to App Window... On Windows?

[Mike H. <mho...@gr...>]

The main issue on the windows side is someone figuring out how to pass 
the gid(?) information around so Chromium can grab the window.  Under 
*nix, this is pretty easy through X11.  I would suggest following along 
the X11 path and see if something similar can be done on the Windows path.

-Mike

ma...@co... wrote:

>Hi all,
>
>So it appears that render_to_app_window doesn't work under Windows.
>
>There's even a comment in the code (in renderspu_wgl.c) that says:
>
>/* The render_to_app_window option
> * is set and we've got a nativeWindow
> * handle, save the handle for
> * later calls to swapbuffers().
> *
> * NOTE: This doesn't work, except
> * for software driven Mesa.
> * We'd need to object link the
> * crappfaker and crserver to be able to share
> * the HDC values between processes.. FIXME!
>*/
>
>So, what I'm planning on trying is the following:
>
>Add a dispatch table to stub called stubDoubleDispatch. The functions in it
>would call stubNativeDispatch.func(someArgs) and stubSpuDispatch.func
>(someArgs).
>
>Does anyone forsee a problem with this?
>
>Thanks,
>Jon
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
>a projector? How fast can you ride your desk chair down the office luge track?
>If you want to score the big prize, get to know the little guy.  
>Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>_______________________________________________
>Chromium-dev mailing list
>Chr...@li...
>https://lists.sourceforge.net/lists/listinfo/chromium-dev
>  
>

[Chromium-dev] Render to App Window... On Windows?

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

Hi all,

So it appears that render_to_app_window doesn't work under Windows.

There's even a comment in the code (in renderspu_wgl.c) that says:

/* The render_to_app_window option
 * is set and we've got a nativeWindow
 * handle, save the handle for
 * later calls to swapbuffers().
 *
 * NOTE: This doesn't work, except
 * for software driven Mesa.
 * We'd need to object link the
 * crappfaker and crserver to be able to share
 * the HDC values between processes.. FIXME!
*/

So, what I'm planning on trying is the following:

Add a dispatch table to stub called stubDoubleDispatch. The functions in it
would call stubNativeDispatch.func(someArgs) and stubSpuDispatch.func
(someArgs).

Does anyone forsee a problem with this?

Thanks,
Jon

[Chromium-dev] Possible Fix for Tilesort + No Context + GL Calls = Crash

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

Hi all,

We were experienceing a problem with an ill-behaved app that was calling
destroyContext(), then calling flush().

Most spu's don't seem to mind this naughtiness, but tilesort appears to crash
under these circumstances.

So here's a modification to opengl_stub/context.c in stubMakeCurrent, around
line 750 or so that seems to work...

if (!context || !window) {
	if (stub.currentContext)
		stub.currentContext->currentDrawable = NULL;
	if (context)
		context->currentDrawable = NULL;
	stub.currentContext = NULL;

	/* BP Viz Change: When making non-current, null out the funcs */
	stubSetDispatch(&stubNULLDispatch);

	return GL_TRUE;  /* OK */
}


Let me know if there are any potentially bad side-effects of this change!


Thanks,
Jon

Jonathan Marbach
BP Center for Visualization
University of Colorado

Re: [Chromium-dev] Dead Connection after crTCPIPReadExact

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

ma...@co... wrote:
> Brian,
> 
> 
>>Occasionally, when I'm developing new code or debugging, etc.
> 
> 
> :) Of course!
> 
> 
>>Do you know if the other end of the socket connection exists, or if
>>that process has terminated?
> 
> 
> I should have given more detail...
> 
> python somefile.conf appname
> 
> appname is acutually a batch file (.bat) that sets some environment variables,
> etc, and then launches the app.

A number of sci-vis apps do that sort of thing.  They're sometimes 
trouble.  Is it possible to launch the application directory without 
using the wrapper script?


> The sequence of events that I'm seeing goes something like this:
> 
> 1) Start mothership - everything's OK
> 2) Start crserver - everything's OK
> 3) Start appfaker - Dead Socket, appfaker exits, mothership exits
> 
> and then...
> 
> 4) The app (appname) starts anyway!
> 
> So I guess that would suggest that the app process is spawning another...
> 
> 
> To be continued...

-Brian

[Chromium-dev] Crashing on a Flush?

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

Hi all,

I've got an app that, by the looks of the log, is crashing on a flush.

Does that ring any bells with anyone?

(I'm just checking quickly with all of you in the hopes of saving many days of
debugging...!)

Thanks,
Jon

ps. To be more specific, if I start the mothership, start a crserver, then
start the app by itself (without crfaker), the app appears to exit suddenly,
reporting a dead socket. The last thing in the log is a flush...

pps. If I start the app using appfaker, it exits almost immediately, with the
only item in the log being a GetIntegerv( GL_VIEWPORT ... )

Re: [Chromium-dev] Dead Connection after crTCPIPReadExact

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

Brian,

> Occasionally, when I'm developing new code or debugging, etc.

:) Of course!

> Do you know if the other end of the socket connection exists, or if
> that process has terminated?

I should have given more detail...

python somefile.conf appname

appname is acutually a batch file (.bat) that sets some environment variables,
etc, and then launches the app.

The sequence of events that I'm seeing goes something like this:

1) Start mothership - everything's OK
2) Start crserver - everything's OK
3) Start appfaker - Dead Socket, appfaker exits, mothership exits

and then...

4) The app (appname) starts anyway!

So I guess that would suggest that the app process is spawning another...


To be continued...


Jon

Re: [Chromium-dev] Dead Connection after crTCPIPReadExact

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

ma...@co... wrote:
> Hi all,
> 
> When I run one of the standard chromium apps in the usual style (python
> somefile.conf appname) I'm having (basically) no trouble.
> 
> But another app I'm running spits out a Dead Socket error as soon as
> crappfaker starts. I've started to trace the error a bit, and it's occurring
> in a __tcpip_read_exact call.

Do you know if the other end of the socket connection exists, or if 
that process has terminated?


> Has anyone run into this kind of thing before?

Occasionally, when I'm developing new code or debugging, etc.

-Brian

[Chromium-dev] Dead Connection after crTCPIPReadExact

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

Hi all,

When I run one of the standard chromium apps in the usual style (python
somefile.conf appname) I'm having (basically) no trouble.

But another app I'm running spits out a Dead Socket error as soon as
crappfaker starts. I've started to trace the error a bit, and it's occurring
in a __tcpip_read_exact call.


Has anyone run into this kind of thing before?


Thanks,
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

[<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,
> 
> 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

[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

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

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

[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/

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

[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

[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