Re: OpenGL-ES

James Amendolagine wrote:
> 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?

No.  That would be a lot more work.  Going through all of Chromium and 
disabling the non-ES functions would be too much work to even 
consider.  Despite all the Python auto-code generation (derived from 
the API description file), there's lots of hand coding that would be 
effected.

One potential short-cut would be to modify the render SPU so that 
calls to non-ES functions would get no-op'd and others (such as 
glClearDepth) would get translated into the ES counterparts (such as 
glClearDepthx).

-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