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