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

Re: [Chromium-dev] CRUT and Darwin

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

I'll try to take a stab at this since I was probably the last person to 
touch the CRUT stuff.

Christopher Waters wrote:

> When running a CRUT program, are the crappfaker's supposed to be 
> capturing system-specific OGL functions?  I've come to a hard wall where 
> the only way to pass it is to disable the 'faking' in app_faker.  The 
> problem seems to be that when the render spu is creating the default 
> window, it makes a context to go with it, but instead of calling the 
> system's functions, it calls the functions in opengl_stub.  I'm 
> wondering if this was intentional?  Knowing if it was or not will help 
> me decide where to go with this. =)

CRUT applications create a windows and a context using Chromium 
functions, not standard system functions.  This is done so that we can 
have full control over the context/window to handle events.  Nothing is 
really done until the renderSPU come up and really does the context and 
window creation.

The CRUT implementation in general is not as clean as it can or should 
be since we have not had many people work with it, on it, or who rely on it.

> 
> There is another problem, but it's more Darwin oriented.  I've spent a 
> good bit of time trying to figure out how to get a handle to GLUT's 
> window for CRUT (in crutserver), but with (OSX's) GLUT being written in 
> Obj-C, things aren't going smoothly.  Would anyone know anything about 
> how to go about doing this?
> 

We have a similar issue in Windows.  In the windows case, there is no 
way to hand around the HDC safely.  I've been working with the folks at 
Stanford Radiology to integrate crserver and crutserver to try to work 
around these issues, but we keep getting stuck.  Since the render SPU is 
dynamically loaded, it's tricky to hand off the window handle.  We might 
  have to somehow integrate the renderSPU into the crutserver to work 
around this.

-Mike

[Chromium-dev] CRUT and Darwin

[Christopher W. <cr...@ms...>]

When running a CRUT program, are the crappfaker's supposed to be 
capturing system-specific OGL functions?  I've come to a hard wall 
where the only way to pass it is to disable the 'faking' in app_faker.  
The problem seems to be that when the render spu is creating the 
default window, it makes a context to go with it, but instead of 
calling the system's functions, it calls the functions in opengl_stub.  
I'm wondering if this was intentional?  Knowing if it was or not will 
help me decide where to go with this. =)

There is another problem, but it's more Darwin oriented.  I've spent a 
good bit of time trying to figure out how to get a handle to GLUT's 
window for CRUT (in crutserver), but with (OSX's) GLUT being written in 
Obj-C, things aren't going smoothly.  Would anyone know anything about 
how to go about doing this?

While I'm on the topic of Darwin, last week I made a patch to update to 
'full' CGL/AGL (faker/render) support in Darwin, but apparently 43k is 
too big of a file to send to the mailing list. =\  I'll most likely 
flesh-out and send an updated patch later this week.

  -Chris Waters

Re: [Chromium-dev] Odd tests in binaryswapspu.c

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

Yes that's obviously a typo...  Fixing and checking in...

-Mike

Brian Paul wrote:
> Keith Whitwell wrote:
> 
>> At lines 521 and 592 in binaryswapspu.c, there is the following test, 
>> presumably a typo?
>>
>>     if(draw_width > 0 && draw_width > 0){
> 
> 
> Yeah, I think the second one should be the height.  Want to fix that?
> 
> -Brian
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] Odd tests in binaryswapspu.c

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

Keith Whitwell wrote:
> At lines 521 and 592 in binaryswapspu.c, there is the following test, 
> presumably a typo?
> 
>     if(draw_width > 0 && draw_width > 0){

Yeah, I think the second one should be the height.  Want to fix that?

-Brian

[Chromium-dev] Odd tests in binaryswapspu.c

[Keith W. <ke...@tu...>]

At lines 521 and 592 in binaryswapspu.c, there is the following test, 
presumably a typo?

	if(draw_width > 0 && draw_width > 0){

Keith

[Chromium-dev] readback + tilesort

[Joong Ho \(Johann\) W. <jh...@st...>]

Hi,

I'm testing a combination of readback and tilesort SPUs, of which the
ultimate purpose is to let sort-last parallel apps be able to render on a
DMX mural display. I wrote a simple test script for the first step, which is
a very simple modification of simplemural.conf.
Simplemural.conf uses a tilesort SPU to render an app in two seperate
(possibly remote) windows.
My intension is just to add a readback SPU on top of the tilesort SPU. At
this stage, it has nothing to do with DMX.

What should be rendered must be the same as that of the original
simplemural.conf, but it is not.
SAME part of the application window is rendered on both of the crserver
windows, i.e. the left half.

Configuration for readback is the simplest, as will be shown below.
Mike Houston's guess is that there may be a bug in arguments for DrawPixels.
Even worse is that when the 'extract_depth' option is turned on, nothing is
drawn at all.

Below is my modified simplemural.conf script. Only a few lines related with
readbackSPU are added and without these, everything works fine.

Thanks in advance for any comment.

- johann.

---

import sys
sys.path.append( "../server" )
from mothership import *

if len(sys.argv) > 1:
        demo = sys.argv[1]
        firstExtra = 2
else:
        demo = "bboxtest"
        firstExtra = 1

# Collect remaining command line params as program options
ExtraOpts = ""
for arg in sys.argv[firstExtra:]:
        ExtraOpts += " " + arg

cr = CR()
cr.MTU( 10*1024*1024 )

TILE_COLS = 2
TILE_ROWS = 1

TILE_WIDTH = 150
TILE_HEIGHT = 300

clientspuname = 'tilesort'
if clientspuname == 'pack' and TILE_ROWS*TILE_COLS != 1:
        print >> sys.stderr, "You cant use the pack SPU with more than one
server."
        sys.exit(0)

tilesortspu = SPU( clientspuname )
#tilesortspu.Conf('preserve_aspect_ratio', 1)
tilesortspu.Conf('bucket_mode', 'Uniform Grid')
tilesortspu.Conf('draw_bbox', 0)
tilesortspu.Conf('bbox_scale', 1.0)
tilesortspu.Conf('dlist_state_tracking', 0)

readbackspu=SPU('readback')
readbackspu.Conf('window_geometry', [ 500, 0, 300, 300 ] )
#readbackspu.Conf('extract_depth', '1')

clientnode = CRApplicationNode( )
clientnode.StartDir( crbindir )
clientnode.SetApplication( demo + ExtraOpts)
clientnode.AddSPU( readbackspu )
clientnode.AddSPU( tilesortspu )

for row in range(TILE_ROWS):
        for col in range(TILE_COLS):
                renderspu = SPU( 'render' )
                renderspu.Conf( 'window_geometry', [col*(TILE_WIDTH+10),
1.1*row*TILE_HEIGHT, TILE_WIDTH, TILE_HEIGHT] )

                node = CRNetworkNode( )
                if clientspuname == 'tilesort':
                        node.AddTile( col*TILE_WIDTH,
(TILE_ROWS-row-1)*TILE_HEIGHT, TILE_WIDTH, TILE_HEIGHT )

                node.Conf('optimize_bucket', 1)
                #node.Conf('vertprog_projection_param', 'ModelViewProj')
                node.AddSPU( renderspu )
                cr.AddNode( node )

                tilesortspu.AddServer( node, protocol='tcpip', port=7000 +
row*TILE_COLS + col )


cr.AddNode( clientnode )

cr.Go()

[Chromium-dev] Darwin CGL Patch

[<cr...@ms...>]

Attached is an archive with a completely new Darwin patch, along with
one extra file needed for the render spu.  The patch includes
everything needed to get chromium to work as intended under Darwin
(..so far).  This is a step beyond Jorge's patch in that it uses CGL in
the app_faker and AGL in the render SPU.

As of right now, this has only been 'fully' tested with the spheres
program, since it uses chromium directly.  It will still work for
non-chromium programs, but I cannot tell you how well it does right
now.  The only SPUs that I have been using are render and tilesort (and
error?), but the others should work as well.

to sum it up:  It all works well enough for me to at least run spheres
tiled across 3 G5s =)

The patch is a cvs diff of today's CVS head.

  -Chris

Re: [Chromium-dev] beginner questions...

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

Iskandar Prins wrote:

> Hello cr-ers, 
> 
> Im fairly new to the chromium system, and i do have a
> couple of questions.
> 
> - Im using ms visual c++ .net 2003 , can i compile
> chromium  under this too? Do i need some special sort
> of options for the compiler or can i just compile
> straight away?

You'll need a few other things like 'make', 'python', and 'perl'.  My 
suggestion is to install cygwin with all of the development tree chosen 
as well as python and perl.

> 
> - Also im using OpenSceneGraph
> (www.openscenegraph.org) as scenegraph api. Is
> Chromium compatible with this?

Yes.  Although OpenRM has specific support for Chromium, i.e. it's 
"Chromium aware", so it will probably provide you with better performance.

> 
> - My last question, im using a 2 pass render
> technique, since im using a non linear distortion
> correction algoritm for projecting onto curved screens
> with projector not in the center. Does Chromium allow
> to use the render to texture option inside opengl?

This gets a little tricky.  In a sort-last configuration, yes.  In this 
configuration, Chromium will only handle the pixels after they have been 
rendered.  I'm going to guess that things will not work as expected in 
sort-last rendering, i.e. the geometry is handled by Chromium.

I should mention that there is a great deal of work to get Chromium to 
work with really odd tiled display configurations.  It might be better 
to adapt the tilesort SPU to handle the complex transformations.  Others 
  might be able to provide more information on this.

-Mike

[Chromium-dev] beginner questions...

[Iskandar P. <ple...@ya...>]

Hello cr-ers, 

Im fairly new to the chromium system, and i do have a
couple of questions.

- Im using ms visual c++ .net 2003 , can i compile
chromium  under this too? Do i need some special sort
of options for the compiler or can i just compile
straight away?

- Also im using OpenSceneGraph
(www.openscenegraph.org) as scenegraph api. Is
Chromium compatible with this?

- My last question, im using a 2 pass render
technique, since im using a non linear distortion
correction algoritm for projecting onto curved screens
with projector not in the center. Does Chromium allow
to use the render to texture option inside opengl?

Regards, 
Iskandar


	
		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/

Re: [Chromium-dev] Windows Tilesort Fix

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

Ricky Uy wrote:
> There have been several posts about a "memory access violation" error 
> when people try to use the tilesort spu. It is because of this that I 
> began using the pack->tilesort->render configuration as a workaround. I 
> found the problem, however, and here is a patch. Put this after line 333 
> in tilesort_window.c:
> 
> /* this should be line 333 */ winInfo->lastY = r.top;
> 
> if(winInfo->lastWidth == 0 || winInfo->lastHeight == 0)
> {
>         if (tilesort_spu.fakeWindowWidth != 0) 
>         {
>                  winInfo->lastWidth = tilesort_spu.fakeWindowWidth;
> 
>                  winInfo->lastHeight = tilesort_spu.fakeWindowHeight;
>          }
> }
> 
> Basically, winInfo->client_wnd is sometimes not NULL, but still 
> currently an invalid handle for purposes of retrieving the window size 
> because the window has not yet been initialized. In this case, the 
> lastWidth and lastHeight variables are going to be 0, and they are never 
> set to the fake_window_dims parameters because it never fell into the 
> if(!winInfo->client) branch. This patch fixes that. This is all 
> application dependent due to the way different applications set up their 
> windows, so that's why it worked before with some programs but not with 
> others.
> 
> You should now be able to do a straight tilesort->render configuration 
> in Windows. Hope this helps some of you out.

I'm checking in the fix, Ricky.  Thanks.

-Brian

Re: [Chromium-dev] Re: Raptor 0.1.1 released

[Alan M. <al...@re...>]

On Mon, 2004-07-19 at 15:27, David Jones wrote:
> Actually, the 'render_to_crut_window' causes the X error.  I'm not sure 
> how the 'render_to_app_window' option behaves in a sort-last 
> configuration.
> 
> By commenting out both, I get the renderspu window and a null rendered 
> crut server winodw that grabs events.  So I can still interact, it's just 
> in the render window.
> 
> -Dave
> 
Yep. That's what I get. It works once I comment out those two lines.

> 
> On Mon, 19 Jul 2004, Mike Houston wrote:
> 
> > Hmmm, that will prevent interaction from working.  But, it sounds like 
> > we will need to find a workaround for the Nvidia drivers and 
> > glXMakeCurrent.  What happens if you just comment out render_to_app_window?
> > 
> > -Mike
> > 
> > David Jones wrote:
> > > So there is a 'partial' fix to this.  Commenting out both
> > > 
> > > renderspu.Conf('render_to_app_window', 1 )
> > > renderspu.Conf('render_to_crut_window', 1 )
> > > 
> > > in the config file fixes things.
> > > 
> > > As best I can tell, the glXMakeCurrent calls made at around line 1120 in 
> > > renderspu_glx.c are freaking out.  Unfortunately, I don't really know 
> > > enough about this code to know what's going on.
> > > 
> > > -Dave
> > > 
> > > 
> > > On Mon, 19 Jul 2004, Mike Houston wrote:
> > > 
> > > 
> > >>Includes David's glXGetProcAddress bug fix.  I should have been using 
> > >>the ARB version...
> > >>
> > >>There is still a bug with Nvidia hardware in sort-last cluster rendering 
> > >>mode to still track down.  It's throwing a invalid drawable error. 
> > >>Since the local rendering version works, this looks like an odd 
> > >>interaction between Chromium and Nvidia's Linux drivers doing sort-last 
> > >>rendering.
> > >>
> > >>-Mike
> > >>
> > >>
> > 
> > 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
-- 
Alan Matsuoka
Global Professional Services
Red Hat Canada, Ltd
mailto:al...@re...

[Chromium-dev] Windows Tilesort Fix

[Ricky Uy <ric...@ya...>]

There have been several posts about a "memory access violation" error when people try to use the tilesort spu. It is because of this that I began using the pack->tilesort->render configuration as a workaround. I found the problem, however, and here is a patch. Put this after line 333 in tilesort_window.c:

/* this should be line 333 */ winInfo->lastY = r.top;

if(winInfo->lastWidth == 0 || winInfo->lastHeight == 0)
{
        if (tilesort_spu.fakeWindowWidth != 0) 
        {
                 winInfo->lastWidth = tilesort_spu.fakeWindowWidth;

                 winInfo->lastHeight = tilesort_spu.fakeWindowHeight;
         }
}

Basically, winInfo->client_wnd is sometimes not NULL, but still currently an invalid handle for purposes of retrieving the window size because the window has not yet been initialized. In this case, the lastWidth and lastHeight variables are going to be 0, and they are never set to the fake_window_dims parameters because it never fell into the if(!winInfo->client) branch. This patch fixes that. This is all application dependent due to the way different applications set up their windows, so that's why it worked before with some programs but not with others. 

You should now be able to do a straight tilesort->render configuration in Windows. Hope this helps some of you out.

Ricky

		
---------------------------------
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!

[Chromium-dev] Re: Raptor 0.1.1 released

[David J. <jo...@mc...>]

Actually, the 'render_to_crut_window' causes the X error.  I'm not sure 
how the 'render_to_app_window' option behaves in a sort-last 
configuration.

By commenting out both, I get the renderspu window and a null rendered 
crut server winodw that grabs events.  So I can still interact, it's just 
in the render window.

-Dave


On Mon, 19 Jul 2004, Mike Houston wrote:

> Hmmm, that will prevent interaction from working.  But, it sounds like 
> we will need to find a workaround for the Nvidia drivers and 
> glXMakeCurrent.  What happens if you just comment out render_to_app_window?
> 
> -Mike
> 
> David Jones wrote:
> > So there is a 'partial' fix to this.  Commenting out both
> > 
> > renderspu.Conf('render_to_app_window', 1 )
> > renderspu.Conf('render_to_crut_window', 1 )
> > 
> > in the config file fixes things.
> > 
> > As best I can tell, the glXMakeCurrent calls made at around line 1120 in 
> > renderspu_glx.c are freaking out.  Unfortunately, I don't really know 
> > enough about this code to know what's going on.
> > 
> > -Dave
> > 
> > 
> > On Mon, 19 Jul 2004, Mike Houston wrote:
> > 
> > 
> >>Includes David's glXGetProcAddress bug fix.  I should have been using 
> >>the ARB version...
> >>
> >>There is still a bug with Nvidia hardware in sort-last cluster rendering 
> >>mode to still track down.  It's throwing a invalid drawable error. 
> >>Since the local rendering version works, this looks like an odd 
> >>interaction between Chromium and Nvidia's Linux drivers doing sort-last 
> >>rendering.
> >>
> >>-Mike
> >>
> >>
> 
> 

[Chromium-dev] Re: Raptor 0.1.1 released

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

Hmmm, that will prevent interaction from working.  But, it sounds like 
we will need to find a workaround for the Nvidia drivers and 
glXMakeCurrent.  What happens if you just comment out render_to_app_window?

-Mike

David Jones wrote:
> So there is a 'partial' fix to this.  Commenting out both
> 
> renderspu.Conf('render_to_app_window', 1 )
> renderspu.Conf('render_to_crut_window', 1 )
> 
> in the config file fixes things.
> 
> As best I can tell, the glXMakeCurrent calls made at around line 1120 in 
> renderspu_glx.c are freaking out.  Unfortunately, I don't really know 
> enough about this code to know what's going on.
> 
> -Dave
> 
> 
> On Mon, 19 Jul 2004, Mike Houston wrote:
> 
> 
>>Includes David's glXGetProcAddress bug fix.  I should have been using 
>>the ARB version...
>>
>>There is still a bug with Nvidia hardware in sort-last cluster rendering 
>>mode to still track down.  It's throwing a invalid drawable error. 
>>Since the local rendering version works, this looks like an odd 
>>interaction between Chromium and Nvidia's Linux drivers doing sort-last 
>>rendering.
>>
>>-Mike
>>
>>

[Chromium-dev] Re: Raptor 0.1.1 released

[David J. <jo...@mc...>]

So there is a 'partial' fix to this.  Commenting out both

renderspu.Conf('render_to_app_window', 1 )
renderspu.Conf('render_to_crut_window', 1 )

in the config file fixes things.

As best I can tell, the glXMakeCurrent calls made at around line 1120 in 
renderspu_glx.c are freaking out.  Unfortunately, I don't really know 
enough about this code to know what's going on.

-Dave


On Mon, 19 Jul 2004, Mike Houston wrote:

> Includes David's glXGetProcAddress bug fix.  I should have been using 
> the ARB version...
> 
> There is still a bug with Nvidia hardware in sort-last cluster rendering 
> mode to still track down.  It's throwing a invalid drawable error. 
> Since the local rendering version works, this looks like an odd 
> interaction between Chromium and Nvidia's Linux drivers doing sort-last 
> rendering.
> 
> -Mike
> 
> 

[Chromium-dev] Raptor 0.1.1 released

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

Includes David's glXGetProcAddress bug fix.  I should have been using 
the ARB version...

There is still a bug with Nvidia hardware in sort-last cluster rendering 
mode to still track down.  It's throwing a invalid drawable error. 
Since the local rendering version works, this looks like an odd 
interaction between Chromium and Nvidia's Linux drivers doing sort-last 
rendering.

-Mike

Re: [Chromium-users] Re: [Chromium-dev] Raptor released

[David J. <jo...@mc...>]

I only changed one line in raptor.cpp (225):

#define GETPROCADDRESS(x) glXGetProcAddress((const GLubyte*) x)

to

#define GETPROCADDRESS(x) glXGetProcAddressARB((const GLubyte*) x)

I also did a 'strings /usr/lib/libGL.so', and the only glXGetProcAddress 
that was listed was glXGetProcAddressARB (ie: nothing listed with the ARB 
stripped).

-Dave


On Mon, 19 Jul 2004, Mike Houston wrote:

> Hmmm...  For linux, I use glXGetProcAddress which should be everywhere. 
>   On windows, wglGetProcAddress *should* work.  Does anyone know what 
> the standard really is here?
> 
> If GetProcAddressARB works for everyone, that's an easy code fix.
> 
> Dave: Which lines in the raptor code are you changing?
> 
> Thanks,
> Mike
> 
> David Jones wrote:
> 
> > Ok, now I got it working.  It seemed like GetProcAddress isn't in my GL 
> > distro, but GetProcAddressARB is.  Since GetProcAddress is defined in the 
> > linked cr libs, that was getting invoked and subsequentally calling the 
> > chromium stuff.
> > 
> > So a non-cr run of raptor *does* work for me when I change GetProcAddress 
> > to GetProcAddressARB.
> > 
> > Weird.
> > 
> > -Dave
> > 
> > 
> > On Mon, 19 Jul 2004, Mike Houston wrote:
> > 
> > 
> >>If you don't feed it "CR" at the end of the command line, there should 
> >>be no chromium stuff loaded.  At least it runs that way for me.  Are you 
> >>using Nvidia's GL library or Chromium's?
> >>
> >>-Mike
> >>
> >>David Jones wrote:
> >>
> >>
> >>>I started that from the command line - no mothership.  Since it's linked 
> >>>against the Cr libs, I'm guessing that the crfaker lib is invoking its 
> >>>opengl stub stuff.
> >>>
> >>>I don't know a way of getting around this without fiddling with raptor 
> >>>code..
> >>>
> >>>-Dave
> >>>
> >>>
> >>>On Mon, 19 Jul 2004, Mike Houston wrote:
> >>>
> >>>
> >>>
> >>>>Can you send me a run not using Chromium?
> >>>>
> >>>>-Mike
> >>>>
> >>>>David Jones wrote:
> >>>>
> >>>>
> >>>>
> >>>>>Yeah, this is an FX board (5900 Ultra on Linux) that supports 
> >>>>>GL_ARB_fragment_program and GL_ARB_vertex_program.
> >>>>>
> >>>>>I've attached the output of a run.  I double checked the paths to 
> >>>>>everything and those seem to look ok.
> >>>>>
> >>>>>-Dave
> >>>>>
> >>>>>On Mon, 19 Jul 2004, Mike Houston wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>I'm willing to bet the some of the extensions failed to load, but it 
> >>>>>>should have assert failed...  What type of Nvidia board is it?  Raptor 
> >>>>>>requires an NV30+.  There are some known issues with the latest Nvidia 
> >>>>>>drivers, but they shouldn't be causing failures with local rendering.
> >>>>>>
> >>>>>>Can you send me the output of Raptor please?  I'll try to take a guess 
> >>>>>>at what I might think is happening.  When I get back in town, I'll try 
> >>>>>>to track down an Nvidia board I can run in my Linux box and see if I can 
> >>>>>>track down these errors.  Things seem to work fine with Nvidia hardware 
> >>>>>>under Windows...
> >>>>>>
> >>>>>>-Mike
> >>>>>>
> >>>>>>
> >>>>>>David Jones wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>I gave this a shot on some of our machines.  Running it locally without 
> >>>>>>>any chromium gives me a blank window.  Running the raptor_1.conf config 
> >>>>>>>starts the app. but quickly bails with the crserver dumping:
> >>>>>>>
> >>>>>>>CR Debug(nitrogen:3568): Done calling crTCPIPConnection
> >>>>>>>CR Debug(nitrogen:3568): Done connecting to server.
> >>>>>>>CR Debug(nitrogen:3568): Received a drawable: 35651585
> >>>>>>>X Error of failed request:  BadMatch (invalid parameter attributes)
> >>>>>>>Major opcode of failed request:  144 (GLX)
> >>>>>>>Minor opcode of failed request:  5 (X_GLXMakeCurrent)
> >>>>>>>Serial number of failed request:  30
> >>>>>>>Current serial number in output stream:  30
> >>>>>>>
> >>>>>>>I've tried the raptor_1.conf with both a local and remote 'crappfaker'.  
> >>>>>>>I'm using a Nvidia 5900 Ultra with the 61.06 Linux drivers.
> >>>>>>>
> >>>>>>>I've also run raptor on my home desktop (Radeon 9600) under windows and it 
> >>>>>>>seems to work fine there.
> >>>>>>>
> >>>>>>>-Dave
> >>>>>>>
> >>>>>>>
> >>>>>>>On Sat, 17 Jul 2004, Mike Houston wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>I very happy to announce that Raptor, the parallel volume rendering 
> >>>>>>>>system written at Stanford using Chromium, has been released.
> >>>>>>>>
> >>>>>>>>http://graphics.stanford.edu/raptor
> >>>>>>>>
> >>>>>>>>The source code, (limited) documentation, and some (large) datasets are 
> >>>>>>>>available.  Give it a go and let me know if there are any issues.  This 
> >>>>>>>>has not been thoroughly tested on Nvidia based clusters, so I'm curious 
> >>>>>>>>how that will go.
> >>>>>>>>
> >>>>>>>>-Mike
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>-------------------------------------------------------
> >>>>>>>>This SF.Net email is sponsored by BEA Weblogic Workshop
> >>>>>>>>FREE Java Enterprise J2EE developer tools!
> >>>>>>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
> >>>>>>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> >>>>>>>>_______________________________________________
> >>>>>>>>Chromium-dev mailing list
> >>>>>>>>Chr...@li...
> >>>>>>>>https://lists.sourceforge.net/lists/listinfo/chromium-dev
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>-------------------------------------------------------
> >>>>>>>This SF.Net email is sponsored by BEA Weblogic Workshop
> >>>>>>>FREE Java Enterprise J2EE developer tools!
> >>>>>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
> >>>>>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> >>>>>>>_______________________________________________
> >>>>>>>Chromium-users mailing list
> >>>>>>>Chr...@li...
> >>>>>>>https://lists.sourceforge.net/lists/listinfo/chromium-users
> >>>>>>
> >>
> 
> 

Re: [Chromium-users] Re: [Chromium-dev] Raptor released

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

I just reread the GLX_ARB_get_proc_address extension.  Obviously, I 
should be using that...

Why Chromium is choking on a bad drawable is a separate issue...  That 
one I'll probably need help tracking since I don't have an Nvidia 
cluster to test on.

-Mike

Mike Houston wrote:

> Hmmm...  For linux, I use glXGetProcAddress which should be everywhere. 
>  On windows, wglGetProcAddress *should* work.  Does anyone know what the 
> standard really is here?
> 
> If GetProcAddressARB works for everyone, that's an easy code fix.
> 
> Dave: Which lines in the raptor code are you changing?
> 
> Thanks,
> Mike
> 
> David Jones wrote:
> 
>> Ok, now I got it working.  It seemed like GetProcAddress isn't in my 
>> GL distro, but GetProcAddressARB is.  Since GetProcAddress is defined 
>> in the linked cr libs, that was getting invoked and subsequentally 
>> calling the chromium stuff.
>>
>> So a non-cr run of raptor *does* work for me when I change 
>> GetProcAddress to GetProcAddressARB.
>>
>> Weird.
>>
>> -Dave
>>
>>
>> On Mon, 19 Jul 2004, Mike Houston wrote:
>>
>>
>>> If you don't feed it "CR" at the end of the command line, there 
>>> should be no chromium stuff loaded.  At least it runs that way for 
>>> me.  Are you using Nvidia's GL library or Chromium's?
>>>
>>> -Mike
>>>
>>> David Jones wrote:
>>>
>>>
>>>> I started that from the command line - no mothership.  Since it's 
>>>> linked against the Cr libs, I'm guessing that the crfaker lib is 
>>>> invoking its opengl stub stuff.
>>>>
>>>> I don't know a way of getting around this without fiddling with 
>>>> raptor code..
>>>>
>>>> -Dave
>>>>
>>>>
>>>> On Mon, 19 Jul 2004, Mike Houston wrote:
>>>>
>>>>
>>>>
>>>>> Can you send me a run not using Chromium?
>>>>>
>>>>> -Mike
>>>>>
>>>>> David Jones wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Yeah, this is an FX board (5900 Ultra on Linux) that supports 
>>>>>> GL_ARB_fragment_program and GL_ARB_vertex_program.
>>>>>>
>>>>>> I've attached the output of a run.  I double checked the paths to 
>>>>>> everything and those seem to look ok.
>>>>>>
>>>>>> -Dave
>>>>>>
>>>>>> On Mon, 19 Jul 2004, Mike Houston wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I'm willing to bet the some of the extensions failed to load, but 
>>>>>>> it should have assert failed...  What type of Nvidia board is 
>>>>>>> it?  Raptor requires an NV30+.  There are some known issues with 
>>>>>>> the latest Nvidia drivers, but they shouldn't be causing failures 
>>>>>>> with local rendering.
>>>>>>>
>>>>>>> Can you send me the output of Raptor please?  I'll try to take a 
>>>>>>> guess at what I might think is happening.  When I get back in 
>>>>>>> town, I'll try to track down an Nvidia board I can run in my 
>>>>>>> Linux box and see if I can track down these errors.  Things seem 
>>>>>>> to work fine with Nvidia hardware under Windows...
>>>>>>>
>>>>>>> -Mike
>>>>>>>
>>>>>>>
>>>>>>> David Jones wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I gave this a shot on some of our machines.  Running it locally 
>>>>>>>> without any chromium gives me a blank window.  Running the 
>>>>>>>> raptor_1.conf config starts the app. but quickly bails with the 
>>>>>>>> crserver dumping:
>>>>>>>>
>>>>>>>> CR Debug(nitrogen:3568): Done calling crTCPIPConnection
>>>>>>>> CR Debug(nitrogen:3568): Done connecting to server.
>>>>>>>> CR Debug(nitrogen:3568): Received a drawable: 35651585
>>>>>>>> X Error of failed request:  BadMatch (invalid parameter attributes)
>>>>>>>> Major opcode of failed request:  144 (GLX)
>>>>>>>> Minor opcode of failed request:  5 (X_GLXMakeCurrent)
>>>>>>>> Serial number of failed request:  30
>>>>>>>> Current serial number in output stream:  30
>>>>>>>>
>>>>>>>> I've tried the raptor_1.conf with both a local and remote 
>>>>>>>> 'crappfaker'.  I'm using a Nvidia 5900 Ultra with the 61.06 
>>>>>>>> Linux drivers.
>>>>>>>>
>>>>>>>> I've also run raptor on my home desktop (Radeon 9600) under 
>>>>>>>> windows and it seems to work fine there.
>>>>>>>>
>>>>>>>> -Dave
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, 17 Jul 2004, Mike Houston wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I very happy to announce that Raptor, the parallel volume 
>>>>>>>>> rendering system written at Stanford using Chromium, has been 
>>>>>>>>> released.
>>>>>>>>>
>>>>>>>>> http://graphics.stanford.edu/raptor
>>>>>>>>>
>>>>>>>>> The source code, (limited) documentation, and some (large) 
>>>>>>>>> datasets are available.  Give it a go and let me know if there 
>>>>>>>>> are any issues.  This has not been thoroughly tested on Nvidia 
>>>>>>>>> based clusters, so I'm curious how that will go.
>>>>>>>>>
>>>>>>>>> -Mike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------
>>>>>>>>> This SF.Net email is sponsored by BEA Weblogic Workshop
>>>>>>>>> FREE Java Enterprise J2EE developer tools!
>>>>>>>>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>>>>>>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>>>>>>>> _______________________________________________
>>>>>>>>> Chromium-dev mailing list
>>>>>>>>> Chr...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------------
>>>>>>>> This SF.Net email is sponsored by BEA Weblogic Workshop
>>>>>>>> FREE Java Enterprise J2EE developer tools!
>>>>>>>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>>>>>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>>>>>>> _______________________________________________
>>>>>>>> Chromium-users mailing list
>>>>>>>> Chr...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/chromium-users
>>>>>>>
>>>>>>>
>>>
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-users] Re: [Chromium-dev] Raptor released

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

Hmmm...  For linux, I use glXGetProcAddress which should be everywhere. 
  On windows, wglGetProcAddress *should* work.  Does anyone know what 
the standard really is here?

If GetProcAddressARB works for everyone, that's an easy code fix.

Dave: Which lines in the raptor code are you changing?

Thanks,
Mike

David Jones wrote:

> Ok, now I got it working.  It seemed like GetProcAddress isn't in my GL 
> distro, but GetProcAddressARB is.  Since GetProcAddress is defined in the 
> linked cr libs, that was getting invoked and subsequentally calling the 
> chromium stuff.
> 
> So a non-cr run of raptor *does* work for me when I change GetProcAddress 
> to GetProcAddressARB.
> 
> Weird.
> 
> -Dave
> 
> 
> On Mon, 19 Jul 2004, Mike Houston wrote:
> 
> 
>>If you don't feed it "CR" at the end of the command line, there should 
>>be no chromium stuff loaded.  At least it runs that way for me.  Are you 
>>using Nvidia's GL library or Chromium's?
>>
>>-Mike
>>
>>David Jones wrote:
>>
>>
>>>I started that from the command line - no mothership.  Since it's linked 
>>>against the Cr libs, I'm guessing that the crfaker lib is invoking its 
>>>opengl stub stuff.
>>>
>>>I don't know a way of getting around this without fiddling with raptor 
>>>code..
>>>
>>>-Dave
>>>
>>>
>>>On Mon, 19 Jul 2004, Mike Houston wrote:
>>>
>>>
>>>
>>>>Can you send me a run not using Chromium?
>>>>
>>>>-Mike
>>>>
>>>>David Jones wrote:
>>>>
>>>>
>>>>
>>>>>Yeah, this is an FX board (5900 Ultra on Linux) that supports 
>>>>>GL_ARB_fragment_program and GL_ARB_vertex_program.
>>>>>
>>>>>I've attached the output of a run.  I double checked the paths to 
>>>>>everything and those seem to look ok.
>>>>>
>>>>>-Dave
>>>>>
>>>>>On Mon, 19 Jul 2004, Mike Houston wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I'm willing to bet the some of the extensions failed to load, but it 
>>>>>>should have assert failed...  What type of Nvidia board is it?  Raptor 
>>>>>>requires an NV30+.  There are some known issues with the latest Nvidia 
>>>>>>drivers, but they shouldn't be causing failures with local rendering.
>>>>>>
>>>>>>Can you send me the output of Raptor please?  I'll try to take a guess 
>>>>>>at what I might think is happening.  When I get back in town, I'll try 
>>>>>>to track down an Nvidia board I can run in my Linux box and see if I can 
>>>>>>track down these errors.  Things seem to work fine with Nvidia hardware 
>>>>>>under Windows...
>>>>>>
>>>>>>-Mike
>>>>>>
>>>>>>
>>>>>>David Jones wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I gave this a shot on some of our machines.  Running it locally without 
>>>>>>>any chromium gives me a blank window.  Running the raptor_1.conf config 
>>>>>>>starts the app. but quickly bails with the crserver dumping:
>>>>>>>
>>>>>>>CR Debug(nitrogen:3568): Done calling crTCPIPConnection
>>>>>>>CR Debug(nitrogen:3568): Done connecting to server.
>>>>>>>CR Debug(nitrogen:3568): Received a drawable: 35651585
>>>>>>>X Error of failed request:  BadMatch (invalid parameter attributes)
>>>>>>>Major opcode of failed request:  144 (GLX)
>>>>>>>Minor opcode of failed request:  5 (X_GLXMakeCurrent)
>>>>>>>Serial number of failed request:  30
>>>>>>>Current serial number in output stream:  30
>>>>>>>
>>>>>>>I've tried the raptor_1.conf with both a local and remote 'crappfaker'.  
>>>>>>>I'm using a Nvidia 5900 Ultra with the 61.06 Linux drivers.
>>>>>>>
>>>>>>>I've also run raptor on my home desktop (Radeon 9600) under windows and it 
>>>>>>>seems to work fine there.
>>>>>>>
>>>>>>>-Dave
>>>>>>>
>>>>>>>
>>>>>>>On Sat, 17 Jul 2004, Mike Houston wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>I very happy to announce that Raptor, the parallel volume rendering 
>>>>>>>>system written at Stanford using Chromium, has been released.
>>>>>>>>
>>>>>>>>http://graphics.stanford.edu/raptor
>>>>>>>>
>>>>>>>>The source code, (limited) documentation, and some (large) datasets are 
>>>>>>>>available.  Give it a go and let me know if there are any issues.  This 
>>>>>>>>has not been thoroughly tested on Nvidia based clusters, so I'm curious 
>>>>>>>>how that will go.
>>>>>>>>
>>>>>>>>-Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>-------------------------------------------------------
>>>>>>>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>>>>>>>FREE Java Enterprise J2EE developer tools!
>>>>>>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>>>>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>>>>>>>_______________________________________________
>>>>>>>>Chromium-dev mailing list
>>>>>>>>Chr...@li...
>>>>>>>>https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>-------------------------------------------------------
>>>>>>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>>>>>>FREE Java Enterprise J2EE developer tools!
>>>>>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>>>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>>>>>>_______________________________________________
>>>>>>>Chromium-users mailing list
>>>>>>>Chr...@li...
>>>>>>>https://lists.sourceforge.net/lists/listinfo/chromium-users
>>>>>>
>>

[Chromium-dev] Raptor released

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

I very happy to announce that Raptor, the parallel volume rendering 
system written at Stanford using Chromium, has been released.

http://graphics.stanford.edu/raptor

The source code, (limited) documentation, and some (large) datasets are 
available.  Give it a go and let me know if there are any issues.  This 
has not been thoroughly tested on Nvidia based clusters, so I'm curious 
how that will go.

-Mike

[Chromium-dev] my own crserver application

[Anthony S. <she...@st...>]

Hello,

 

I would like to write my own crserver application, so that basically I
can render into my own application window rather than the one the
crserver creates.  Does anyone know of work that has already done this?
It would be great if I could start from an existing approach to this.

 

 

 

_Tony

 

Re: [Chromium-dev] New Darwin Patch

[Jorge L. W. <jo...@jl...>]

On Jul 15, 2004, at 11:38 AM, Christopher Waters wrote:

>
> On Jul 15, 2004, at 11:58 AM, Jorge Luis Williams wrote:
>> I was running some experiments and I noticed that some AGL and GLX 
>> programs generate CGL calls which are not documented.  Have you run 
>> into these problems?  I always assumed one of the undocumented calls 
>> linked the window with the context..is this what you're doing in the 
>> render spu??
>
> Actually, I have, and all I've done with them is forward them to their 
> respective native CGL functions.  I'm not sure what the non-context 
> parameters are yet, but I've been working to figure/find that out =)
> These functions include:
> 	CGLSetSurface (4 parameters with the first being CGLContextObj)
> 	CGLGetSurface (4 parameters with the first being CGLContextObj)
> 	CGLUpdateContext (1 paramter, which is a CGLContextObj)

Yup, I ran into these too :-)

>
>> How functional is your patch have you tested with AGL, GLX and Cocoa 
>> apps?  If your patch isn't fully functional yet maybe we should merge 
>> both of our patches since mine appears to be fully functional for GLX 
>> apps.  Take a look at what I've done and let's see if we can add a 
>> compilation option where we can compile with only GLX support and 
>> this is fully functional for now or we can compile CGL which will be 
>> experimental till you get your stuff up and running. This will get 
>> people up and running on Darwin fast.
>>
>> On the other hand if you feel CGL is complete enough to support CGL, 
>> AGL, and GLX apps - then maybe we should ignore my patch completely 
>> :-)
>
> I have only been able to test it with the chromium demo programs, and 
> some of the samples that Apple provides.  While trying to test a Cocoa 
> ogl app, I noticed that chromium (starting mothership) doesn't handle 
> pathnames with spaces in them very well, even the "\ " spaces =(
>
> At this time, I would assume that it works with everything except AGL 
> ... that is, -if- NSOpenGL doesnt do anything with contexts =\
>

I'm very impressed with your progress!!  If most things work (CGL, 
GLX), then it might be a good idea to back out of my patch and just use 
yours.
I'm really looking forward to your patch.

-jOrGe W.

Re: [Chromium-dev] New Darwin Patch

[Alan M. <al...@re...>]

On Thu, 2004-07-15 at 13:28, Alan Matsuoka wrote:
> On Thu, 15 Jul 2004, Jorge Luis Williams wrote:
> 
> > 
> > On Jul 15, 2004, at 9:04 AM, Alan Matsuoka wrote:
> > 
> > >On Thu, 2004-07-15 at 10:03, Jorge Luis Williams wrote:
> > >>
> > >>Attached is a new Darwin patch.  This is basically just an update of
> > >>the patch I submitted last December for Chromium 1.5.  This one is
> > >>based on CVS as of today.  Please see documentation for compilation
> > >>instructions.  Again this only works for GLX apps -- it's still a ways
> > >>to go before CGL support.
> > >>
> > >>Christopher, I realize this may set you back a bit, but I still feel 
> > >>we
> > >>should head in the CGL direction as opposed to AGL.  Please read my
> > >>previous posts. Let me know if you have any questions.
> > >>
> > >>Would someone mind importing this patch to CVS?
Done
> > >I would if I could but your version of diff is generating a patch that
> > >can't be read by patch.
> > 
> > Did you try to gunziping it first?   I had to gzip it up so that the 
> > mailing list wouldn't reject my msg because of its large size.  If 
> > you're still having problems after that please let me know.
> 
> That's not the problem. Never mind, I found out what it is and I've got the 
> patch applied to my source tree.
> 
> > 
> > -jOrGe W.
> > 
> > >
> > >>Thanx,
> > >>
> > >>-jOrGe W.
> > >>
> > >>
> > >>
> > >-- 
> > >Alan Matsuoka
> > >Global Professional Services
> > >Red Hat Canada, Ltd
> > >mailto:al...@re...
> > >
> > >
> > >
> > >-------------------------------------------------------
> > >This SF.Net email is sponsored by BEA Weblogic Workshop
> > >FREE Java Enterprise J2EE developer tools!
> > >Get your free copy of BEA WebLogic Workshop 8.1 today.
> > >http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> > >_______________________________________________
> > >Chromium-dev mailing list
> > >Chr...@li...
> > >https://lists.sourceforge.net/lists/listinfo/chromium-dev
> > >
> > 
> 
> 
> Alan Matsuoka
> Professional Services
> Red Hat Canada, Ltd
> mailto:al...@re... Tel: (416) 482-2661 x250 / Fax: (416) 482-6299
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
-- 
Alan Matsuoka
Global Professional Services
Red Hat Canada, Ltd
mailto:al...@re...

Re: [Chromium-dev] New Darwin Patch

[Christopher W. <cr...@ms...>]

On Jul 15, 2004, at 11:58 AM, Jorge Luis Williams wrote:
> I was running some experiments and I noticed that some AGL and GLX 
> programs generate CGL calls which are not documented.  Have you run 
> into these problems?  I always assumed one of the undocumented calls 
> linked the window with the context..is this what you're doing in the 
> render spu??
>

Sorry, I forgot to reply to that last part.  CGLSetSurface is one of 
the more important undocumented functions for attaching a context to a 
window, but that's not what I use in the render spu; well, not directly 
at least :)

In the render spu, I'm using AGL to do all of the drawing and whatnot, 
which includes using aglSetDrawable to attach a context to a 
window/drawable.  This isnt the linking I mentioned, though.  What I 
was referring to was using the window's "RefCon" to store which context 
that window is using.  This is used later in the other functions that 
need the context, but only have the window.  It's a little trick I 
found in the sample programs that Apple has :)

I am thinking of doing this in the fakerlib, but I am not sure if it 
would be ok to do this in there.  I am looking into this right now.

  -Chris

Re: [Chromium-dev] New Darwin Patch

[Christopher W. <cr...@ms...>]

On Jul 15, 2004, at 11:58 AM, Jorge Luis Williams wrote:
> I was running some experiments and I noticed that some AGL and GLX 
> programs generate CGL calls which are not documented.  Have you run 
> into these problems?  I always assumed one of the undocumented calls 
> linked the window with the context..is this what you're doing in the 
> render spu??

Actually, I have, and all I've done with them is forward them to their 
respective native CGL functions.  I'm not sure what the non-context 
parameters are yet, but I've been working to figure/find that out =)
These functions include:
	CGLSetSurface (4 parameters with the first being CGLContextObj)
	CGLGetSurface (4 parameters with the first being CGLContextObj)
	CGLUpdateContext (1 paramter, which is a CGLContextObj)

> How functional is your patch have you tested with AGL, GLX and Cocoa 
> apps?  If your patch isn't fully functional yet maybe we should merge 
> both of our patches since mine appears to be fully functional for GLX 
> apps.  Take a look at what I've done and let's see if we can add a 
> compilation option where we can compile with only GLX support and this 
> is fully functional for now or we can compile CGL which will be 
> experimental till you get your stuff up and running. This will get 
> people up and running on Darwin fast.
>
> On the other hand if you feel CGL is complete enough to support CGL, 
> AGL, and GLX apps - then maybe we should ignore my patch completely 
> :-)

I have only been able to test it with the chromium demo programs, and 
some of the samples that Apple provides.  While trying to test a Cocoa 
ogl app, I noticed that chromium (starting mothership) doesn't handle 
pathnames with spaces in them very well, even the "\ " spaces =(

At this time, I would assume that it works with everything except AGL 
... that is, -if- NSOpenGL doesnt do anything with contexts =\

  -Chris