Re: OpenGL-ES

On Thu, 2004-09-16 at 18:46, Brian Paul wrote:
> James Amendolagine wrote:
> > On Thu, 2004-09-16 at 13:41, Mike Houston wrote:
> > 
> >>I don't think anyone is currently working on this, but the extensions 
> >>should be easy to add if you were so inclined.  You can pretty much just 
> >>replicate the floating point versions and use the new types.
> >>
> >>The EGS stuff looks to be more tricky...
> > 
> > Actually I believe it's EGL..
> > 
> > 
> > By the way, I've just started working with Chromium (a couple of weeks
> > ago), and I'm very impressed. 
> > 
> > 
> > So if no-one has done this before, I'll just jump in and do it myself. 
> > 
> > 
> > I don't understand the internals well enough yet to have a very useful
> > opinion, but one of my concerns with adding the calls as extensions is
> > will the SPU's still work? ie will the state tracking still be valid?
> > 
> > 
> > When any of the OpenGL version of these ES calls are made: 
> > glClearColorx
> > glClearDepthf
> > glClearDepthx
> > glColor4x
> > glDepthRangef
> > glDepthRangex
> > 
> > I imagine that chromium records the state. I guess that I could just
> > replicate the state management that is being done within the associated
> > OpenGL Chromium call. 
> > 
> > so I add a call glClearColorx, and look at the origional glClearColor,
> > and just replicate most of the function...
> > 
> > It looks like this would be done in state_tracker/state_buffer.c
> 
> Would it be feasible to simply translate the glFoox functions into the 
> corresponding conventional OpenGL functions at the dispatch layer? 
> That is:
> 
> void glClearDepthx(GLclampx value)
> {
>     glClearDepth(FixedToDouble(value));
> }
> 
> That could be implemented in the opengl_stub/* files fairly easily, I 
> think, without having to touch the rest of the system.
> 
> I haven't looked at the ES functions closely enough to know if there's 
> any potential pitfalls.

I'm going to spend the rest of the day stepping through the debugger to
get a better feel for what's going on inside chromium -- to avoid
getting too deep into a discussion and only guessing a the details. 




My first thoughts on the above are this though: 
void glClearDepthx(GLclampx value)
> {
>     glClearDepth(FixedToDouble(value));
> }
> 
> 

This would give chromium the ability to look like gl-es to gl-es
applications, and render on OpenGL targets. It would also allow the
entire chromium system, spu's etc to function -- but would it give the
ability to render to gl-es targets? 

I would like to be able to write some SPU's to do some analysis on gl-es
systems, so it might be best to have more of an "es-native" version of
chromium -- but this might break spu's etc. within the system, and force
a gl-es version of many components. 

Anyway I'll have a more informed opinion soon. 



> I haven't looked at the ES functions closely enough to know if there's
> any potential pitfalls.

Offhand this looks good. Some early examples of the es gl.h were missing
the glGet commands (and chromium might like to have these available) but
I believe that the spec says that they should be there. 


> 
> -Brian


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php