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

Re: [Chromium-dev] Re: [Chromium-users] Config tool and .crsite

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

On Tue, 2004-09-28 at 16:17, Sean Ahern wrote:
> Volz, Bill (WRVO) (Bill.Volz) wrote:
> > 1) I'm totally confused about what I need to run the config tool.  I
> > find almost any combination of wx with GTK and Python and none of them
> > are the versions that work.  If someone knows a version that works,
> > please send me a link to the down load page for them.
> 
> I'm using python 2.2.3, wxPythonGTK 2.4.2.4, and gtk2-2.2.4.
> 
That's correct on one of my machines running RHEL3 WS.
You can fetch the wxPythonGTK rpm from sourceforge.

> > 2) what is the format of the .crsite f

ile?  It seems to be created by
> > the config tool, but if I can't get that to work or doesn't want to
> > use that, then how does one build it?
> 
> If you're using the latest Chromium, you no longer need a .crsite file
> to run tiled displays.  See the docs in doc/{autostart,dmx}.html
> 
> If you really want a .crsite file for the config tool, you can find an
> example at the bottom of doc/configtool.html
> 
> -Sean
> 
> __
> sea...@ll...
> 925-422-1648
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> 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] RE: [Chromium-users] Config tool and .crsite

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

On Tue, 2004-09-28 at 16:11, Volz, Bill (WRVO) (Bill.Volz) wrote:
> RHEL 3.0
> 
Hmm.. Are you getting error messages from python when you run
configtool? If so, I should be able to help you.



> Bill V>
> 
> -----Original Message-----
> From: Alan Matsuoka [mailto:al...@re...] 
> Sent: Tuesday, September 28, 2004 3:06 PM
> To: Volz, Bill (WRVO) (Bill.Volz)
> Cc: chr...@li...;
> chr...@li...
> Subject: Re: [Chromium-users] Config tool and .crsite
> 
> 
> On Tue, 2004-09-28 at 15:39, Volz, Bill (WRVO) (Bill.Volz) wrote:
> > Two items:
> > 
> > 1) I'm totally confused about what I need to run the config tool. I 
> > find almost any combination of wx with GTK and Python and none of them
> 
> > are the versions that work. If someone knows a version that works, 
> > please send me a link to the down load page for them.
> > 
> What OS ? which version ?
> > 2) what is the format of the .crsite file? It seems to be created by 
> > the config tool, but if I can't get that to work or doesn't want to 
> > use that, then how does one build it?
> > 
> > Thanks,
> > 
> > > William R Volz,  Senior Research Geophysicist
> > > 
> > > ChevronTexaco
> > > Energy Technology Company
> > > Subsurface Characterization Business Line
> > > Interpretation Product Development & Support
> > > 4800 Fournace Place, Bellaire, TX, 77401
> > > Tel 713 432 6666  Fax 713 432 2536
> > > 
> > > <mailto:bil...@ch...>
> > > This message may contain confidential information that is 
> > > proprietary to ChevronTexaco and is intended only for the use of the
> 
> > > parties to whom it is addressed. If you are not an intended 
> > > recipient, you are hereby notified that any disclosure, copying, 
> > > distribution or use of any information in this message is strictly 
> > > prohibited. If you have received this message in error, please 
> > > notify me immediately at the telephone number noted above.
> > > 
> > > 
> -- 
> Alan Matsuoka
> Global Professional Services
> Red Hat Canada, Ltd
> mailto:al...@re...
> 
> 
> 
-- 
Alan Matsuoka
Global Professional Services
Red Hat Canada, Ltd
mailto:al...@re...

[Chromium-dev] Re: [Chromium-users] Config tool and .crsite

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

Volz, Bill (WRVO) (Bill.Volz) wrote:
> 1) I'm totally confused about what I need to run the config tool.  I
> find almost any combination of wx with GTK and Python and none of them
> are the versions that work.  If someone knows a version that works,
> please send me a link to the down load page for them.

I'm using python 2.2.3, wxPythonGTK 2.4.2.4, and gtk2-2.2.4.

> 2) what is the format of the .crsite file?  It seems to be created by
> the config tool, but if I can't get that to work or doesn't want to
> use that, then how does one build it?

If you're using the latest Chromium, you no longer need a .crsite file
to run tiled displays.  See the docs in doc/{autostart,dmx}.html

If you really want a .crsite file for the config tool, you can find an
example at the bottom of doc/configtool.html

-Sean

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

[Chromium-dev] Re: [Chromium-users] Config tool and .crsite

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

On Tue, 2004-09-28 at 15:39, Volz, Bill (WRVO) (Bill.Volz) wrote:
> Two items:
> 
> 1) I'm totally confused about what I need to run the config tool. I find
> almost any combination of wx with GTK and Python and none of them are
> the versions that work. If someone knows a version that works, please
> send me a link to the down load page for them.
> 
What OS ? which version ?
> 2) what is the format of the .crsite file? It seems to be created by the
> config tool, but if I can't get that to work or doesn't want to use
> that, then how does one build it?
> 
> Thanks,
> 
> > William R Volz,  Senior Research Geophysicist
> > 
> > ChevronTexaco 
> > Energy Technology Company
> > Subsurface Characterization Business Line
> > Interpretation Product Development & Support
> > 4800 Fournace Place, Bellaire, TX, 77401
> > Tel 713 432 6666  Fax 713 432 2536
> > 
> > <mailto:bil...@ch...>
> > This message may contain confidential information that is proprietary
> > to ChevronTexaco and is intended only for the use of the parties to
> > whom it is addressed. If you are not an intended recipient, you are
> > hereby notified that any disclosure, copying, distribution or use of
> > any information in this message is strictly prohibited. If you have
> > received this message in error, please notify me immediately at the
> > telephone number noted above.
> > 
> > 
-- 
Alan Matsuoka
Global Professional Services
Red Hat Canada, Ltd
mailto:al...@re...

Re: [Chromium-dev] More Darwin updates and notes

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

Christopher Waters wrote:
> The attached patch has various fixes, mainly for Darwin, including:
>     Absolute path names during building.  The dynamic linker wasn't 
> liking the relative paths, making things very difficult.
>     The OSX ogl headers weren't needed in chromium.h.  Moved them to 
> spu.h and compensated elsewhere
>     Config Tool naming discrepancy (in wxSizer::Add) fixed.  Added 
> Darwin names to SPU searching.  Same regex's needed to escape the period.
>     Various Darwin adjustments in the faker.  Still don't know the 
> details on the last three functions.
>     Removed CoreFoundation framework from util (Unnecessary).
>     Added more error handling to Framework and Bundle loading.  Still 
> not very complete.
> 
> Could someone commit this?  That is, if there's no problems with it.

In app_faker.c you changed a number of lines from:

#ifdef USE_FRAMEWORKS

to read:

#if USE_FRAMEWORKS

Some compilers complain if you try to test the value of an undefined 
preprocessor symbol.  It seems to me that USE_FRAMEWORKS will only get 
defined on Darwin.  So, using #ifdef USE_FRAMEWORKS would seem to be a 
better choice.

-Brian

Re: [Chromium-dev] OpenGL-ES

[James A. <ame...@vi...>]

>James Amendolagine wrote:
>> I believe that I've come full circle on this. I'm going to do my first
>> try at this as an extension, or an extension-like addition. 
>> 
>> Just for some feedback on the documentation, it looks like the extension

>> addition instructions are out-of-date. 
>> 
>>   * Update the extension strings in spu/state_tracker/state_limits.c as
>>     well. 
>>   * Extensions which add new OpenGL functions are more work. The OpenGL
>>     API dispatcher is defined by the functions in
>>     cr/glapi_parser/system_header/CR_GL.H. New API functions must be
>>     added there. 
>> 
>> 
>> 
>> 
>> I could not find spu/state_tracker/state_limits.c
>> or glapi_parser/system_header/CR_GL.H
>
>I'm updating the docs now.  state_limits.c is in the cr/state_tracker/ 
>directory.

I hope that I am not double posting here. It seems like my other e-mail is broken..


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

I was wrong about this. The get's are delebirately missing in the ES 1.0spec.
(I was looking at the 1.1 spec). 



As an experiment, I've added one ES call to the system glClearColorx I did not
add the fixed datatype, just added a the call name. -- After adding the call
to Mesa to test, I was able to run an app with the call and it made it through
a modified app->chromium->modifiedMesa->gfx. 



I kept notes on every modification that I needed to do, so maybe at one point
I can give them to you to update the documentation.

 This is my current take on doing this port (I would like some feedback):I can
just add the entire GLES API as the standard path-gl, and whatever GLES extensions
as extensions. So Chromium will be a superset of GL and GLES. There may need
to be some modifications to the gl loading calls to attach the es libraries.


I have not throughly looked at this yet. I have also not looked at the glx/egl
fixups required. 

Assuming that the loading and glx/egl portion is smoothed out, this is the scenereo:
-Chromium will then be the superset of (gl+gles) 
-When the gl portion initializes, it will discover if the system is GLor GLES.

-If the system is GL, then application es calls can either error out, or be
converted on the fly to the appropiate GL call by the render spu. 
-If the system is GLES then the application GL calls can error out, or possibly
be converted on the fly like above. 


Jamie 







>
>CR_GL.H no longer exists.  New functions are defined in the 
>glapi_parser/APIspec.txt file.
>
>-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
>_______________________________________________
>Chromium-dev mailing list
>Chr...@li...
>https://lists.sourceforge.net/lists/listinfo/chromium-dev
>
>

Re: [Chromium-dev] Re: [Chromium-users] Nvidia 3000G Support

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

Chartrand Katharine N. wrote:
> I am running nvidia 3000gs with the 6591 driver and linux 2.4.26 and I 
> am not sure I have a swaplock or framelock problem.

Unless you explicitly set the proper Render SPU options for framelock, 
you're not using that facility.  And since I was never able to get the 
framelock feature to work here, I'm not sure the Render SPU code is up 
to snuff.


> Everything 
> seems to be in sync unless I have a very large data set in a particular 
> application (not running over chromium).  With this application, an image 
> on our multipanel display will be six inches out of alignment between 
> panels as we translate it quickly.

That sounds like ordinary network/Chromium latency.
The tilesort SPU sends geometry in round-robin order to the servers so 
there is some latency in the updates from one server to the next.


>  My hunch, however, was that the 
> problem was with  
> the application, not the cards because we see the same behavior with our 
> wildcats cards.  

Probably Chromium, not the application.


> This 6591 driver was given to us by nvidia to stop a combination of 
> problems: stereo flickering and chromium apps crashing, and it seems to 
> have fixed them both.  I don't believe it is a released driver, but I will 
> ask our nvidia contact if I can distribute it.  My questions are:
> 
> 1. can I have a copy of your test program so I can see if I have this 
> framelock problem (and don't know it!) with this 6591 driver.

Attached.  I've sent it to so many people I figured everyone had it by 
now. :)


> 2. what are the exact symptoms of this type of framelock, swaplock 
> problem. For example, would stereo work at all with this framelock problem 
> you describe.  Would you just get a flicker in the stereo? 

Stereo would probably "work" but the left/right synchronization among 
all the screens wouldn't occur.  It would confuse your eyes and maybe 
give you a headache after a while.

-Brian

Re: [Chromium-dev] Re: [Chromium-users] Nvidia 3000G Support

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

Sean Ahern wrote:
> Ricky Uy wrote:
> 
>>Hi, I remember that a little while ago there was talk that some people
>>were implementing 3000G support in Chromium to handle frame synch
>>using some of the API that is provided by Nvidia with the cards.  Has
>>this been completed?  If not, what issues are left to resolve?
> 
> 
> This has yet to be completed.  We are working with nVidia to resolve the
> technical issues, but have yet to reach resolution.  Since we haven't
> been able to fix the problem with test apps, there as of yet no reason
> to fully integrate the API changes into Chromium or DMX, though there is
> some support in the render SPU.  (see is_swap_master, num_swap_client,
> nv_swap_clients, nv_swap_group, and swap_master_url)
> 
> I'm sure Brian has more comments about this.

Not much to add.  I haven't heard of anyone having any luck with the 
3000G swaplock or framelock feature.  NVIDIA and other parties have my 
test program.  Until it works with the test programs, there's no point 
in trying with Chromium.


-Brian

[Chromium-dev] More Darwin updates and notes

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

The attached patch has various fixes, mainly for Darwin, including:
	Absolute path names during building.  The dynamic linker wasn't liking 
the relative paths, making things very difficult.
	The OSX ogl headers weren't needed in chromium.h.  Moved them to spu.h 
and compensated elsewhere
	Config Tool naming discrepancy (in wxSizer::Add) fixed.  Added Darwin 
names to SPU searching.  Same regex's needed to escape the period.
	Various Darwin adjustments in the faker.  Still don't know the details 
on the last three functions.
	Removed CoreFoundation framework from util (Unnecessary).
	Added more error handling to Framework and Bundle loading.  Still not 
very complete.

Could someone commit this?  That is, if there's no problems with it.

  -Chris

[Chromium-dev] Re: [Chromium-users] Nvidia 3000G Support

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

Ricky Uy wrote:
> Hi, I remember that a little while ago there was talk that some people
> were implementing 3000G support in Chromium to handle frame synch
> using some of the API that is provided by Nvidia with the cards.  Has
> this been completed?  If not, what issues are left to resolve?

This has yet to be completed.  We are working with nVidia to resolve the
technical issues, but have yet to reach resolution.  Since we haven't
been able to fix the problem with test apps, there as of yet no reason
to fully integrate the API changes into Chromium or DMX, though there is
some support in the render SPU.  (see is_swap_master, num_swap_client,
nv_swap_clients, nv_swap_group, and swap_master_url)

I'm sure Brian has more comments about this.

> And what kind of support was this exactly?  Was this to make sure that
> the framebuffers in each of the render spu machines had the right
> frame in it, and that SwapBuffers() calls would be made at about the
> same time along with an Nvidia call to make sure they refreshed at the
> same time?

There are two types of synchronization that one might desire.  One is
swaplock, where windows are put in to a "swap group".  When one window
is told to swap, all of them are guaranteed to swap at the same time.
This can be accomplished to a large degree in user-space software.  In
fact, Chromium already support for this in the tilesort SPU (see
sync_on_swap, sync_on_finish).  In many cases, any tearing that might
happen is very minor and isn't even visible to most people.  GLXProxy in
DMX also has support for this if you pass "-glxsyncswap" to DMX.

The second type of synchronization is framelock, where the left and
right buffer swaps are synchronized between cards.  This type of swap
cannot be done in software.  It also requires a higher degree of
synchronization, as any tearing is easily visible to someone wearing
stereo glasses.  This is the one that we're having the most trouble
with.

> I am experiencing some frames getting ahead of others in my wall
> display and I am interested in pursuing this to fix the problem.  The
> other thing I was thinking might be causing the messed up frame synch
> is that I have a 25% overlap on each tile, causing the tilesort spu to
> perform more computations.  So yeah, any information on the Nvidia
> stuff would be greatly appreciated.  Thanks so much!

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

[Chromium-dev] Nvidia 3000G Support

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

Hi, I remember that a little while ago there was talk that some people were implementing 3000G support in Chromium to handle frame synch using some of the API that is provided by Nvidia with the cards. Has this been completed? If not, what issues are left to resolve? 

And what kind of support was this exactly? Was this to make sure that the framebuffers in each of the render spu machines had the right frame in it, and that SwapBuffers() calls would be made at about the same time along with an Nvidia call to make sure they refreshed at the same time? 

I am experiencing some frames getting ahead of others in my wall display and I am interested in pursuing this to fix the problem. The other thing I was thinking might be causing the messed up frame synch is that I have a 25% overlap on each tile, causing the tilesort spu to perform more computations. So yeah, any information on the Nvidia stuff would be greatly appreciated. Thanks so much!

Ricky

		
---------------------------------
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!

[Chromium-dev] FileClients broken?

[Jeremy W. S. <jw...@cs...>]

I only just upgraded to 1.7.  Now one of my configuration scripts,
unchanged from what I used with 1.6, doesn't work.  I'm using a file
client.  crserver terminates with this message:

CR Error(alpina:16739): Bad Mothership response: Never heard of faker host
alpina.  Expected one of:
Terminated

Notice that the expected hosts list is null.  I seem to recall traffic in
the recent past about some aspect of the hostname matching having been
changed recently?  Any suggestions?

Jeremy

-- 
Jeremy W. Sheaffer
jw...@cs...
http://cs.virginia.edu/~jws9c/



             /*********************************************
             * The Moving Finger writes; and having writ, *
             *    Moves on: nor all thy piety nor wit     *
             *  Shall lure it back to cancel half a line  *
             *  Nor all thy tears wash out a word of it.  *
             *                                            *
             *                       -Omar Khayyam        *
             *********************************************/

Re: [Chromium-dev] OpenGL-ES

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

James Amendolagine wrote:
> I believe that I've come full circle on this. I'm going to do my first
> try at this as an extension, or an extension-like addition. 
> 
> Just for some feedback on the documentation, it looks like the extension
> addition instructions are out-of-date. 
> 
>   * Update the extension strings in spu/state_tracker/state_limits.c as
>     well. 
>   * Extensions which add new OpenGL functions are more work. The OpenGL
>     API dispatcher is defined by the functions in
>     cr/glapi_parser/system_header/CR_GL.H. New API functions must be
>     added there. 
> 
> 
> 
> 
> I could not find spu/state_tracker/state_limits.c
> or glapi_parser/system_header/CR_GL.H

I'm updating the docs now.  state_limits.c is in the cr/state_tracker/ 
directory.

CR_GL.H no longer exists.  New functions are defined in the 
glapi_parser/APIspec.txt file.

-Brian

Re: [Chromium-dev] OpenGL-ES

[James A. <ame...@vi...>]

I believe that I've come full circle on this. I'm going to do my first
try at this as an extension, or an extension-like addition. 

Just for some feedback on the documentation, it looks like the extension
addition instructions are out-of-date. 

  * Update the extension strings in spu/state_tracker/state_limits.c as
    well. 
  * Extensions which add new OpenGL functions are more work. The OpenGL
    API dispatcher is defined by the functions in
    cr/glapi_parser/system_header/CR_GL.H. New API functions must be
    added there. 




I could not find spu/state_tracker/state_limits.c
or glapi_parser/system_header/CR_GL.H

Jamie

Re: [Chromium-dev] Chromium "DMX for Windows"

[H. <oyv...@zy...>]

> > Perhaps Chromium could store the source + binaries, and create a "help
> > wanted" posting?
>=20
> Well, we could put a tarball of your code on the website/download page=20
> and see what happens.

That would be wonderful!



>=20
> -Brian
--=20
=D8yvind Harboe
http://www.zylin.com

[Chromium-dev] Chromium and PyOpenGL

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

Has anyone had any luck running python OpenGL programs with chromium?  
I've been playing around with various things in an attempt to get it to 
work properly, but it seems that the way PyOpenGL does things makes it 
a little... difficult.

I've also been working on a CRUT interface for python, but it's hardly 
complete (again, thanks to PyOpenGL).  Would anyone else be interested 
in this?  I've ported the spheres program to python to test this as 
well, if you're also interested in that.

  -Chris

Re: [Chromium-dev] Chromium "DMX for Windows"

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

=D8yvind Harboe wrote:
> ons, 15.09.2004 kl. 16.23 skrev Brian Paul:
>=20
>>=D8yvind Harboe wrote:
>>
>>>I took the liberty of copying my answer to the chromium mailing list.
>>>
>>>On Wed, 2004-09-15 at 04:59, Hu Wei wrote:
>>>
>>>
>>>>Did you modify Chromium source code to implement this windows OpenGL =
cluster rendering?=20
>>>
>>>
>>>To clarify:=20
>>>
>>>- there is no communication between my video driver and Chromium yet.
>>>- I did not modify the Chromium code
>>>- If the video driver was approperiately modified to establish the
>>>necessary communication with Chromium, then most likely very few chang=
es
>>>would be required to Chromium.
>>
>>Have you considered making your code a separate project?
>>
>>Just as DMX is separate from Chromium, perhaps your "DMX for Windows"=20
>>should be too.
>=20
>=20
> Unfortunally I don't have the time to work on this project, but I
> thought it was a shame not to at least offer what I've done so far to
> anyone interested in taking it further.
>=20
> Perhaps Chromium could store the source + binaries, and create a "help
> wanted" posting?

Well, we could put a tarball of your code on the website/download page=20
and see what happens.

-Brian

Re: [Chromium-dev] OpenGL-ES

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

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

Re: [Chromium-dev] OpenGL-ES

[James A. <ja...@it...>]

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

Re: [Chromium-dev] OpenGL-ES

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

I agree that this usage scenario makes sense.  However, sort-last 
rendering like this doesn't require that many changes to Chromium for ES 
support.  For example, you wouldn't need much besides the glDrawPixels, 
glWindow, glRasterPos ES versions of those calls and dealing with the 
EGL stuff.

What I was suggesting is that using a cluster of embedded cores might 
not make sense.  However, if high powered chips running OpenGL-ES from 
say Sony or IBM made their way to market, then I could see the need to 
have Chromium be able to deal with OpenGL-ES commands.  It also might 
make sense to write a SPU that will translate from GL to OpenGL-ES so 
that off the shelf apps can be run on such devices.  However, as you and 
I have said, the biggest hurdle to the embedded space will be 
compilation and code size.

I didn't mean to discount the idea, I just wasn't sure what the end 
goals were.  I mean, we've supported other wacky ideas like PS2 and Xbox 
support...  ;-)

-Mike

ta...@su... wrote:
> Mike,
> 
> an example of an embedded device using Chromium is provided in a paper 
> from Lamberti et al "An accelerated remote graphics architecture for 
> PDAs" which you may find interesting. They used a Chromium cluster and a 
> PDA as the visualisation client using 802.11b for communication. 
> Basically the problem with integration of Chromium to mobile clients is 
> as you say a compilation issue and getting all the right tools together 
> but a solid OpenGL port is also essential since there aren't that many 
> OpenGL implementations out there for mobile clients.
> 
> Another issue to consider is the fact that both NVidia and ATI are 
> producing mobile 3D cores which we'll probably see in the market soon 
> enough hence bringing Chromium to mobile platforms can potentially 
> provide advanced graphics features using custom made SPUs that address 
> performance/image quality needs of a mobile client. Usage of Chromium 
> for embedded devices and not just mobile devices (e.g set-top boxes, 
> games consoles) can potentially have quite an impact in the way 3D 
> graphics is addressed for these platforms in my opinion.
> 
> Regards,
> Anthony
> 
> 
> using OpenGL ES for thin clients such as mobile phones and PDAs does 
> have its merits. Lamerti et al. in their paper on
> 
> --On ÐÝìðôç, 16 Óåðôåìâñßïõ 2004 1:10 ìì -0700 Mike Houston 
> <mho...@gr...> wrote:
> 
>> What do you mean?  ES is just a subset of GL, so the API support is
>> already in Chromium +/- a few special features that may be added along
>> the way for low power devices.  The main issue seems to be getting
>> Chromium compiled for the various embedded systems.
>>
>> But, it begs the question, why would you want to run Chromium on embedded
>> GL chips that are not designed to be fast, but low power?
>>
>> -Mike
>>
>> James Amendolagine wrote:
>>
>>> Has anyone done any work to make an ES port?
>>>
>>> Jamie
>>>
>>>
>>> -------------------------------------------------------
>>> 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
>>> _______________________________________________
>>> Chromium-dev mailing list
>>> Chr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>
>>
>>
>> -------------------------------------------------------
>> 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
>> _______________________________________________
>> Chromium-dev mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 

Re: [Chromium-dev] OpenGL-ES

[<ta...@su...>]

Mike,

an example of an embedded device using Chromium is provided in a paper from =

Lamberti et al "An accelerated remote graphics architecture for PDAs" which =

you may find interesting. They used a Chromium cluster and a PDA as the=20
visualisation client using 802.11b for communication. Basically the problem =

with integration of Chromium to mobile clients is as you say a compilation=20
issue and getting all the right tools together but a solid OpenGL port is=20
also essential since there aren't that many OpenGL implementations out=20
there for mobile clients.

Another issue to consider is the fact that both NVidia and ATI are=20
producing mobile 3D cores which we'll probably see in the market soon=20
enough hence bringing Chromium to mobile platforms can potentially provide=20
advanced graphics features using custom made SPUs that address=20
performance/image quality needs of a mobile client. Usage of Chromium for=20
embedded devices and not just mobile devices (e.g set-top boxes, games=20
consoles) can potentially have quite an impact in the way 3D graphics is=20
addressed for these platforms in my opinion.

Regards,
Anthony


using OpenGL ES for thin clients such as mobile phones and PDAs does have=20
its merits. Lamerti et al. in their paper on

--On =D0=DD=EC=F0=F4=E7, 16 =D3=E5=F0=F4=E5=EC=E2=F1=DF=EF=F5 2004 1:10 =
=EC=EC -0700 Mike Houston=20
<mho...@gr...> wrote:

> What do you mean?  ES is just a subset of GL, so the API support is
> already in Chromium +/- a few special features that may be added along
> the way for low power devices.  The main issue seems to be getting
> Chromium compiled for the various embedded systems.
>
> But, it begs the question, why would you want to run Chromium on embedded
> GL chips that are not designed to be fast, but low power?
>
> -Mike
>
> James Amendolagine wrote:
>> Has anyone done any work to make an ES port?
>>
>> Jamie
>>
>>
>> -------------------------------------------------------
>> 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
>> _______________________________________________
>> Chromium-dev mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] OpenGL-ES

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

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.

-Brian

Re: [Chromium-dev] OpenGL-ES

[James A. <ja...@it...>]

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
 






> -Mike
> 
> James Amendolagine wrote:
> 
> > On Thu, 2004-09-16 at 13:12, Mike Houston wrote:
> > 
> >>To clarify the last message, the OES extensions would need to be added 
> >>for 1.1 functional support:
> >>
> > 
> > 
> > Yes. Plus these (and some fixed point data types): 
> > 
> > 
> > GLAPI void APIENTRY glAlphaFuncx (GLenum func, GLclampx ref);
> > GLAPI void APIENTRY glClearColorx (GLclampx red, GLclampx green,
> > GLclampx blue, GLclampx alpha);
> > GLAPI void APIENTRY glClearDepthf (GLclampf depth);
> > GLAPI void APIENTRY glClearDepthx (GLclampx depth);
> > GLAPI void APIENTRY glColor4x (GLfixed red, GLfixed green, GLfixed blue,
> > GLfixed alpha);
> > GLAPI void APIENTRY glDepthRangef (GLclampf zNear, GLclampf zFar);
> > GLAPI void APIENTRY glDepthRangex (GLclampx zNear, GLclampx zFar);
> > GLAPI void APIENTRY glFogx (GLenum pname, GLfixed param);
> > GLAPI void APIENTRY glFogxv (GLenum pname, const GLfixed *params);
> > GLAPI void APIENTRY glFrustumf (GLfloat left, GLfloat right, GLfloat
> > bottom, GLfloat top, GLfloat zNear, GLfloat zFar);
> > GLAPI void APIENTRY glFrustumx (GLfixed left, GLfixed right, GLfixed
> > bottom, GLfixed top, GLfixed zNear, GLfixed zFar);
> > GLAPI void APIENTRY glLightModelx (GLenum pname, GLfixed param);
> > GLAPI void APIENTRY glLightModelxv (GLenum pname, const GLfixed
> > *params);
> > GLAPI void APIENTRY glLightx (GLenum light, GLenum pname, GLfixed
> > param);
> > GLAPI void APIENTRY glLightxv (GLenum light, GLenum pname, const GLfixed
> > *params);
> > GLAPI void APIENTRY glLineWidthx (GLfixed width);
> > GLAPI void APIENTRY glLoadMatrixx (const GLfixed *m);
> > GLAPI void APIENTRY glMaterialx (GLenum face, GLenum pname, GLfixed
> > param);
> > GLAPI void APIENTRY glMaterialxv (GLenum face, GLenum pname, const
> > GLfixed *params);
> > GLAPI void APIENTRY glMultMatrixf (const GLfloat *m);
> > GLAPI void APIENTRY glMultMatrixx (const GLfixed *m);
> > GLAPI void APIENTRY glMultiTexCoord4x (GLenum target, GLfixed s, GLfixed
> > t, GLfixed r, GLfixed q);
> > GLAPI void APIENTRY glNormal3x (GLfixed nx, GLfixed ny, GLfixed nz);
> > GLAPI void APIENTRY glOrthof (GLfloat left, GLfloat right, GLfloat
> > bottom, GLfloat top, GLfloat zNear, GLfloat zFar);
> > GLAPI void APIENTRY glOrthox (GLfixed left, GLfixed right, GLfixed
> > bottom, GLfixed top, GLfixed zNear, GLfixed zFar);
> > GLAPI void APIENTRY glPointSizex (GLfixed size);
> > GLAPI void APIENTRY glPolygonOffsetx (GLfixed factor, GLfixed units);
> > GLAPI void APIENTRY glRotatex (GLfixed angle, GLfixed x, GLfixed y,
> > GLfixed z);
> > GLAPI void APIENTRY glSampleCoveragex (GLclampx value, GLboolean
> > invert);
> > GLAPI void APIENTRY glScalex (GLfixed x, GLfixed y, GLfixed z);
> > GLAPI void APIENTRY glTexEnvx (GLenum target, GLenum pname, GLfixed
> > param);
> > GLAPI void APIENTRY glTexEnvxv (GLenum target, GLenum pname, const
> > GLfixed *params);
> > GLAPI void APIENTRY glTexParameterx (GLenum target, GLenum pname,
> > GLfixed param);
> > GLAPI void APIENTRY glTranslatex (GLfixed x, GLfixed y, GLfixed z);
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >>/*****************************************************************************************/
> >>/*                                 OES extension functions 
> >>                  */
> >>/*****************************************************************************************/
> >>/* OES_matrix_palette */
> >>GLAPI void APIENTRY glCurrentPaletteMatrixOES (GLuint index);
> >>GLAPI void APIENTRY glLoadPaletteFromModelViewMatrixOES (void);
> >>GLAPI void APIENTRY glMatrixIndexPointerOES (GLint size, GLenum type, 
> >>GLsizei stride, GLvoid *pointer);
> >>GLAPI void APIENTRY glWeightPointerOES (GLint size, GLenum type, GLsizei 
> >>stride, GLvoid *pointer);
> >>
> >>/* OES_point_size_array */
> >>GLAPI void APIENTRY glPointSizePointerOES (GLenum type, GLsizei stride, 
> >>const GLvoid *pointer);
> >>
> >>/* OES_draw_texture */
> >>GLAPI void APIENTRY glDrawTexsOES (GLshort x, GLshort y, GLshort z, 
> >>GLshort width, GLshort height);
> >>GLAPI void APIENTRY glDrawTexiOES (GLint x, GLint y, GLint z, GLint 
> >>width, GLint height);
> >>GLAPI void APIENTRY glDrawTexfOES (GLfloat x, GLfloat y, GLfloat z, 
> >>GLfloat width, GLfloat height);
> >>GLAPI void APIENTRY glDrawTexxOES (GLfixed x, GLfixed y, GLfixed z, 
> >>GLfixed width, GLfixed height);
> >>
> >>GLAPI void APIENTRY glDrawTexsvOES (GLshort *coords);
> >>GLAPI void APIENTRY glDrawTexivOES (GLint *coords);
> >>GLAPI void APIENTRY glDrawTexfvOES (GLfloat *coords);
> >>GLAPI void APIENTRY glDrawTexxvOES (GLfixed *coords);
> >>
> >>-Mike
> >>
> >>James Amendolagine wrote:
> >>
> >>
> >>>Has anyone done any work to make an ES port? 
> >>>
> >>>Jamie
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>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
> >>>_______________________________________________
> >>>Chromium-dev mailing list
> >>>Chr...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/chromium-dev
> > 
> > 
> > 
> > -------------------------------------------------------
> > 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
> > _______________________________________________
> > Chromium-dev mailing list
> > Chr...@li...
> > https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] OpenGL-ES

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

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

-Mike

James Amendolagine wrote:

> On Thu, 2004-09-16 at 13:12, Mike Houston wrote:
> 
>>To clarify the last message, the OES extensions would need to be added 
>>for 1.1 functional support:
>>
> 
> 
> Yes. Plus these (and some fixed point data types): 
> 
> 
> GLAPI void APIENTRY glAlphaFuncx (GLenum func, GLclampx ref);
> GLAPI void APIENTRY glClearColorx (GLclampx red, GLclampx green,
> GLclampx blue, GLclampx alpha);
> GLAPI void APIENTRY glClearDepthf (GLclampf depth);
> GLAPI void APIENTRY glClearDepthx (GLclampx depth);
> GLAPI void APIENTRY glColor4x (GLfixed red, GLfixed green, GLfixed blue,
> GLfixed alpha);
> GLAPI void APIENTRY glDepthRangef (GLclampf zNear, GLclampf zFar);
> GLAPI void APIENTRY glDepthRangex (GLclampx zNear, GLclampx zFar);
> GLAPI void APIENTRY glFogx (GLenum pname, GLfixed param);
> GLAPI void APIENTRY glFogxv (GLenum pname, const GLfixed *params);
> GLAPI void APIENTRY glFrustumf (GLfloat left, GLfloat right, GLfloat
> bottom, GLfloat top, GLfloat zNear, GLfloat zFar);
> GLAPI void APIENTRY glFrustumx (GLfixed left, GLfixed right, GLfixed
> bottom, GLfixed top, GLfixed zNear, GLfixed zFar);
> GLAPI void APIENTRY glLightModelx (GLenum pname, GLfixed param);
> GLAPI void APIENTRY glLightModelxv (GLenum pname, const GLfixed
> *params);
> GLAPI void APIENTRY glLightx (GLenum light, GLenum pname, GLfixed
> param);
> GLAPI void APIENTRY glLightxv (GLenum light, GLenum pname, const GLfixed
> *params);
> GLAPI void APIENTRY glLineWidthx (GLfixed width);
> GLAPI void APIENTRY glLoadMatrixx (const GLfixed *m);
> GLAPI void APIENTRY glMaterialx (GLenum face, GLenum pname, GLfixed
> param);
> GLAPI void APIENTRY glMaterialxv (GLenum face, GLenum pname, const
> GLfixed *params);
> GLAPI void APIENTRY glMultMatrixf (const GLfloat *m);
> GLAPI void APIENTRY glMultMatrixx (const GLfixed *m);
> GLAPI void APIENTRY glMultiTexCoord4x (GLenum target, GLfixed s, GLfixed
> t, GLfixed r, GLfixed q);
> GLAPI void APIENTRY glNormal3x (GLfixed nx, GLfixed ny, GLfixed nz);
> GLAPI void APIENTRY glOrthof (GLfloat left, GLfloat right, GLfloat
> bottom, GLfloat top, GLfloat zNear, GLfloat zFar);
> GLAPI void APIENTRY glOrthox (GLfixed left, GLfixed right, GLfixed
> bottom, GLfixed top, GLfixed zNear, GLfixed zFar);
> GLAPI void APIENTRY glPointSizex (GLfixed size);
> GLAPI void APIENTRY glPolygonOffsetx (GLfixed factor, GLfixed units);
> GLAPI void APIENTRY glRotatex (GLfixed angle, GLfixed x, GLfixed y,
> GLfixed z);
> GLAPI void APIENTRY glSampleCoveragex (GLclampx value, GLboolean
> invert);
> GLAPI void APIENTRY glScalex (GLfixed x, GLfixed y, GLfixed z);
> GLAPI void APIENTRY glTexEnvx (GLenum target, GLenum pname, GLfixed
> param);
> GLAPI void APIENTRY glTexEnvxv (GLenum target, GLenum pname, const
> GLfixed *params);
> GLAPI void APIENTRY glTexParameterx (GLenum target, GLenum pname,
> GLfixed param);
> GLAPI void APIENTRY glTranslatex (GLfixed x, GLfixed y, GLfixed z);
> 
> 
> 
> 
> 
> 
> 
>>/*****************************************************************************************/
>>/*                                 OES extension functions 
>>                  */
>>/*****************************************************************************************/
>>/* OES_matrix_palette */
>>GLAPI void APIENTRY glCurrentPaletteMatrixOES (GLuint index);
>>GLAPI void APIENTRY glLoadPaletteFromModelViewMatrixOES (void);
>>GLAPI void APIENTRY glMatrixIndexPointerOES (GLint size, GLenum type, 
>>GLsizei stride, GLvoid *pointer);
>>GLAPI void APIENTRY glWeightPointerOES (GLint size, GLenum type, GLsizei 
>>stride, GLvoid *pointer);
>>
>>/* OES_point_size_array */
>>GLAPI void APIENTRY glPointSizePointerOES (GLenum type, GLsizei stride, 
>>const GLvoid *pointer);
>>
>>/* OES_draw_texture */
>>GLAPI void APIENTRY glDrawTexsOES (GLshort x, GLshort y, GLshort z, 
>>GLshort width, GLshort height);
>>GLAPI void APIENTRY glDrawTexiOES (GLint x, GLint y, GLint z, GLint 
>>width, GLint height);
>>GLAPI void APIENTRY glDrawTexfOES (GLfloat x, GLfloat y, GLfloat z, 
>>GLfloat width, GLfloat height);
>>GLAPI void APIENTRY glDrawTexxOES (GLfixed x, GLfixed y, GLfixed z, 
>>GLfixed width, GLfixed height);
>>
>>GLAPI void APIENTRY glDrawTexsvOES (GLshort *coords);
>>GLAPI void APIENTRY glDrawTexivOES (GLint *coords);
>>GLAPI void APIENTRY glDrawTexfvOES (GLfloat *coords);
>>GLAPI void APIENTRY glDrawTexxvOES (GLfixed *coords);
>>
>>-Mike
>>
>>James Amendolagine wrote:
>>
>>
>>>Has anyone done any work to make an ES port? 
>>>
>>>Jamie
>>>
>>>
>>>-------------------------------------------------------
>>>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
>>>_______________________________________________
>>>Chromium-dev mailing list
>>>Chr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] OpenGL-ES

[James A. <ja...@it...>]

On Thu, 2004-09-16 at 13:12, Mike Houston wrote:
> To clarify the last message, the OES extensions would need to be added 
> for 1.1 functional support:
> 

Yes. Plus these (and some fixed point data types): 


GLAPI void APIENTRY glAlphaFuncx (GLenum func, GLclampx ref);
GLAPI void APIENTRY glClearColorx (GLclampx red, GLclampx green,
GLclampx blue, GLclampx alpha);
GLAPI void APIENTRY glClearDepthf (GLclampf depth);
GLAPI void APIENTRY glClearDepthx (GLclampx depth);
GLAPI void APIENTRY glColor4x (GLfixed red, GLfixed green, GLfixed blue,
GLfixed alpha);
GLAPI void APIENTRY glDepthRangef (GLclampf zNear, GLclampf zFar);
GLAPI void APIENTRY glDepthRangex (GLclampx zNear, GLclampx zFar);
GLAPI void APIENTRY glFogx (GLenum pname, GLfixed param);
GLAPI void APIENTRY glFogxv (GLenum pname, const GLfixed *params);
GLAPI void APIENTRY glFrustumf (GLfloat left, GLfloat right, GLfloat
bottom, GLfloat top, GLfloat zNear, GLfloat zFar);
GLAPI void APIENTRY glFrustumx (GLfixed left, GLfixed right, GLfixed
bottom, GLfixed top, GLfixed zNear, GLfixed zFar);
GLAPI void APIENTRY glLightModelx (GLenum pname, GLfixed param);
GLAPI void APIENTRY glLightModelxv (GLenum pname, const GLfixed
*params);
GLAPI void APIENTRY glLightx (GLenum light, GLenum pname, GLfixed
param);
GLAPI void APIENTRY glLightxv (GLenum light, GLenum pname, const GLfixed
*params);
GLAPI void APIENTRY glLineWidthx (GLfixed width);
GLAPI void APIENTRY glLoadMatrixx (const GLfixed *m);
GLAPI void APIENTRY glMaterialx (GLenum face, GLenum pname, GLfixed
param);
GLAPI void APIENTRY glMaterialxv (GLenum face, GLenum pname, const
GLfixed *params);
GLAPI void APIENTRY glMultMatrixf (const GLfloat *m);
GLAPI void APIENTRY glMultMatrixx (const GLfixed *m);
GLAPI void APIENTRY glMultiTexCoord4x (GLenum target, GLfixed s, GLfixed
t, GLfixed r, GLfixed q);
GLAPI void APIENTRY glNormal3x (GLfixed nx, GLfixed ny, GLfixed nz);
GLAPI void APIENTRY glOrthof (GLfloat left, GLfloat right, GLfloat
bottom, GLfloat top, GLfloat zNear, GLfloat zFar);
GLAPI void APIENTRY glOrthox (GLfixed left, GLfixed right, GLfixed
bottom, GLfixed top, GLfixed zNear, GLfixed zFar);
GLAPI void APIENTRY glPointSizex (GLfixed size);
GLAPI void APIENTRY glPolygonOffsetx (GLfixed factor, GLfixed units);
GLAPI void APIENTRY glRotatex (GLfixed angle, GLfixed x, GLfixed y,
GLfixed z);
GLAPI void APIENTRY glSampleCoveragex (GLclampx value, GLboolean
invert);
GLAPI void APIENTRY glScalex (GLfixed x, GLfixed y, GLfixed z);
GLAPI void APIENTRY glTexEnvx (GLenum target, GLenum pname, GLfixed
param);
GLAPI void APIENTRY glTexEnvxv (GLenum target, GLenum pname, const
GLfixed *params);
GLAPI void APIENTRY glTexParameterx (GLenum target, GLenum pname,
GLfixed param);
GLAPI void APIENTRY glTranslatex (GLfixed x, GLfixed y, GLfixed z);






> /*****************************************************************************************/
> /*                                 OES extension functions 
>                   */
> /*****************************************************************************************/
> /* OES_matrix_palette */
> GLAPI void APIENTRY glCurrentPaletteMatrixOES (GLuint index);
> GLAPI void APIENTRY glLoadPaletteFromModelViewMatrixOES (void);
> GLAPI void APIENTRY glMatrixIndexPointerOES (GLint size, GLenum type, 
> GLsizei stride, GLvoid *pointer);
> GLAPI void APIENTRY glWeightPointerOES (GLint size, GLenum type, GLsizei 
> stride, GLvoid *pointer);
> 
> /* OES_point_size_array */
> GLAPI void APIENTRY glPointSizePointerOES (GLenum type, GLsizei stride, 
> const GLvoid *pointer);
> 
> /* OES_draw_texture */
> GLAPI void APIENTRY glDrawTexsOES (GLshort x, GLshort y, GLshort z, 
> GLshort width, GLshort height);
> GLAPI void APIENTRY glDrawTexiOES (GLint x, GLint y, GLint z, GLint 
> width, GLint height);
> GLAPI void APIENTRY glDrawTexfOES (GLfloat x, GLfloat y, GLfloat z, 
> GLfloat width, GLfloat height);
> GLAPI void APIENTRY glDrawTexxOES (GLfixed x, GLfixed y, GLfixed z, 
> GLfixed width, GLfixed height);
> 
> GLAPI void APIENTRY glDrawTexsvOES (GLshort *coords);
> GLAPI void APIENTRY glDrawTexivOES (GLint *coords);
> GLAPI void APIENTRY glDrawTexfvOES (GLfloat *coords);
> GLAPI void APIENTRY glDrawTexxvOES (GLfixed *coords);
> 
> -Mike
> 
> James Amendolagine wrote:
> 
> > Has anyone done any work to make an ES port? 
> > 
> > Jamie
> > 
> > 
> > -------------------------------------------------------
> > 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
> > _______________________________________________
> > Chromium-dev mailing list
> > Chr...@li...
> > https://lists.sourceforge.net/lists/listinfo/chromium-dev