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

Re: [Chromium-dev] OpenGL-ES

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

OpenGL-ES also defines an API for pixelformat/drawable/context 
management (like GLX or WGL) called "EGS": 
http://www.khronos.org/cgi-bin/fetch/fetch.cgi?egl_1_1

Perhaps Jamie wants to run an app that uses the EGS interface on Chromium.

Chromium doesn't support that yet, but it probably wouldn't be too 
hard to implement.

-Brian

Mike Houston 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

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

To clarify the last message, the OES extensions would need to be added 
for 1.1 functional support:

/*****************************************************************************************/
/*                                 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

Re: [Chromium-dev] OpenGL-ES

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

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

[Chromium-dev] OpenGL-ES

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

Has anyone done any work to make an ES port? 

Jamie

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

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

ons, 15.09.2004 kl. 16.23 skrev Brian Paul:
> =D8yvind Harboe wrote:
> > I took the liberty of copying my answer to the chromium mailing list.
> >=20
> > On Wed, 2004-09-15 at 04:59, Hu Wei wrote:
> >=20
> >>Did you modify Chromium source code to implement this windows OpenGL cl=
uster rendering?=20
> >=20
> >=20
> > To clarify:=20
> >=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 change=
s
> > would be required to Chromium.
>=20
> Have you considered making your code a separate project?
>=20
> Just as DMX is separate from Chromium, perhaps your "DMX for Windows"=20
> should be too.

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.

Perhaps Chromium could store the source + binaries, and create a "help
wanted" posting?

> >>I am very interested with your work. It is just what I want. Could you =
send me
> >>sources and binaries for refrence?=20
> >=20
> >=20
> > I'm hoping that this code will find a new home in the Chromium communit=
y
> > and eventually grow into a "Chromium  Windows video driver".
>=20
> Can your video driver be used without Chromium and serve a useful=20
> purpose? =20

Nothing comes to mind(except as a testing tool of e.g CygWin X server on
multiple monitors).

> If so, then it sounds like it should be an independent project.
>
> -Brian
--=20
=D8yvind Harboe
http://www.zylin.com

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

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

=D8yvind Harboe wrote:
> I took the liberty of copying my answer to the chromium mailing list.
>=20
> On Wed, 2004-09-15 at 04:59, Hu Wei wrote:
>=20
>>Did you modify Chromium source code to implement this windows OpenGL cl=
uster rendering?=20
>=20
>=20
> To clarify:=20
>=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 change=
s
> 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.


>>I am very interested with your work. It is just what I want. Could you =
send me
>>sources and binaries for refrence?=20
>=20
>=20
> I'm hoping that this code will find a new home in the Chromium communit=
y
> and eventually grow into a "Chromium  Windows video driver".

Can your video driver be used without Chromium and serve a useful=20
purpose?  If so, then it sounds like it should be an independent project.

-Brian

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

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

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 clus=
ter 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 changes
would be required to Chromium.

> I am very interested with your work. It is just what I want. Could you se=
nd me
> sources and binaries for refrence?=20

I'm hoping that this code will find a new home in the Chromium community
and eventually grow into a "Chromium  Windows video driver".

> Thanks!

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

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

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

tir, 14.09.2004 kl. 18.40 skrev Brian Paul:
> =D8yvind Harboe wrote:
> > A while back I was looking at Chromium, but my client needed it to run
> > unmodified Windows OpenGL applications.
> >=20
> > Perhaps there is a solution to this problem at this time, but otherwise
> > I have a small piece to the puzzle that my client is interested in
> > contributing to the Chromium community, should it be interested: a
> > virtual Windows video driver.
> >=20
> > - allows any number of virtual video cards to be defined.=20
> > - GDI support(useful for rendering userinterface).
> > - OpenGL support, rendered into memory frame buffer. Tested with
> > unmodified Windows OpenGL apps, appears to run fine.
> >=20
> > I'll be happy to answer any questions and to email the source + binarie=
s
> > to anyone interested.
> >=20
> > Some more information about what Cyviz cluster wall product can be foun=
d
> > on this page:
> >=20
> > http://www.cyviz.com/products_products_xed_clusterwall.html
>=20
>=20
> I guess I'm not sure what you're saying.=20

I'll try to clarify.

The problem:

I'd like to run Windows GDI+OpenGL applications without modifying them
or using a Chromium specific launch procedure.

I believe I have a small part of the solution:

- I've written a video driver
- This video driver renders to a frame buffer in RAM instead of a
graphics card
- The "missing piece" in this video driver is the code necessary to
communicate with Chromium.=20
- Obviously someone would have to write the videodriver<->Chromimum
interface code.=20

>  If you want to contribute=20
> some code for Chromium CVS go ahead.  I'll check it in, so long as=20
> there's not a high risk of breaking things.

The video driver does not communicate in any way with Chromimum, but
perhaps it would make sense to commit it to a "work in progress"
directory?

It could be useful in encouraging discussion and minor patches to clean
up the driver in preparation for Chromium work.

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

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

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

=D8yvind Harboe wrote:
> A while back I was looking at Chromium, but my client needed it to run
> unmodified Windows OpenGL applications.
>=20
> Perhaps there is a solution to this problem at this time, but otherwise
> I have a small piece to the puzzle that my client is interested in
> contributing to the Chromium community, should it be interested: a
> virtual Windows video driver.
>=20
> - allows any number of virtual video cards to be defined.=20
> - GDI support(useful for rendering userinterface).
> - OpenGL support, rendered into memory frame buffer. Tested with
> unmodified Windows OpenGL apps, appears to run fine.
>=20
> I'll be happy to answer any questions and to email the source + binarie=
s
> to anyone interested.
>=20
> Some more information about what Cyviz cluster wall product can be foun=
d
> on this page:
>=20
> http://www.cyviz.com/products_products_xed_clusterwall.html


I guess I'm not sure what you're saying.  If you want to contribute=20
some code for Chromium CVS go ahead.  I'll check it in, so long as=20
there's not a high risk of breaking things.

-Brian

Re: [Chromium-dev] fastdep

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

Christopher Waters wrote:
> Is a python port of the fastdeps.pl still needed (as said in the TO-DO 
> file)? I've written one up, and attached it to this.
> 
> While writing it, I discovered a bug in the perl version: the expression 
> "/^-I(.+)\/$/" on line 92 should be "/^-I(.+\/)$/" in order to properly 
> recognize include paths with a trailing slash.
> 
> If it is still needed, could someone check to see that the python 
> version works correctly? I also didn't know exactly what to put at the 
> top, as well (copyright?)

I think you can put your own copyright statement at the top, but use 
the regular Cr license.

I'll check the script in now though.

-Brian

[Chromium-dev] Chromium "DMX for Windows"

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

A while back I was looking at Chromium, but my client needed it to run
unmodified Windows OpenGL applications.

Perhaps there is a solution to this problem at this time, but otherwise
I have a small piece to the puzzle that my client is interested in
contributing to the Chromium community, should it be interested: a
virtual Windows video driver.

- allows any number of virtual video cards to be defined.=20
- GDI support(useful for rendering userinterface).
- OpenGL support, rendered into memory frame buffer. Tested with
unmodified Windows OpenGL apps, appears to run fine.

I'll be happy to answer any questions and to email the source + binaries
to anyone interested.

Some more information about what Cyviz cluster wall product can be found
on this page:

http://www.cyviz.com/products_products_xed_clusterwall.html

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

Re: [Chromium-dev] fastdep

[Greg H. <hu...@gm...>]

This is great -- it removes one of the things that people have to do
to build Chromium on Windows (e.g., install perl).

Assuming this works OK, I'd be all in favor of replacing fastdep.pl with this.

On Fri, 10 Sep 2004 17:35:26 -0500, Christopher Waters <cr...@ms...> wrote:
> Is a python port of the fastdeps.pl still needed (as said in the TO-DO
> file)?  I've written one up, and attached it to this.
> 
> While writing it, I discovered a bug in the perl version:  the
> expression "/^-I(.+)\/$/" on line 92 should be "/^-I(.+\/)$/" in order
> to properly recognize include paths with a trailing slash.
> 
> If it is still needed, could someone check to see that the python
> version works correctly?  I also didn't know exactly what to put at the
> top, as well (copyright?)
> 
>   -Chris Waters
> 
> 
> 
> 



-- 
Greg Humphreys, Assistant Professor
Department of Computer Science, University of Virginia
http://www.cs.virginia.edu/~humper/

Re: [Chromium-dev] IEEE Vis 2004 Workshop

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

I should have been more explicit.  I meant immediately following the 
workshop or the next day, although that would conflict with the conference.

-Mike

Brian Paul wrote:
> Mike Houston wrote:
> 
>> Brian Paul, Praveen Bhaniramka, and I will be doing another workshop 
>> at Vis this year similar to the one last year.  The workshop is on 
>> Sunday, Oct. 10th.  More information can be found at:
>>
>> http://vis.computer.org/vis2004/session/workshops.html#w2
>>
>> If you are interested, please join us.  If you know others that might 
>> be interested, please forward this information onto them.  If you 
>> can't make it, we will try to make all of the slides available online.
>>
>> Also, if there is interest in a Chromium User's Meeting/BOF following 
>> the workshop, which already includes lots of information on Chromium, 
>> please let us know.
> 
> 
> I don't plan on staying all week so a meeting earlier in the week would 
> be best for me.
> 
> -Brian

Re: [Chromium-dev] IEEE Vis 2004 Workshop

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

Mike Houston wrote:
> Brian Paul, Praveen Bhaniramka, and I will be doing another workshop at 
> Vis this year similar to the one last year.  The workshop is on Sunday, 
> Oct. 10th.  More information can be found at:
> 
> http://vis.computer.org/vis2004/session/workshops.html#w2
> 
> If you are interested, please join us.  If you know others that might be 
> interested, please forward this information onto them.  If you can't 
> make it, we will try to make all of the slides available online.
> 
> Also, if there is interest in a Chromium User's Meeting/BOF following 
> the workshop, which already includes lots of information on Chromium, 
> please let us know.

I don't plan on staying all week so a meeting earlier in the week 
would be best for me.

-Brian

[Chromium-dev] IEEE Vis 2004 Workshop

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

Brian Paul, Praveen Bhaniramka, and I will be doing another workshop at 
Vis this year similar to the one last year.  The workshop is on Sunday, 
Oct. 10th.  More information can be found at:

http://vis.computer.org/vis2004/session/workshops.html#w2

If you are interested, please join us.  If you know others that might be 
interested, please forward this information onto them.  If you can't 
make it, we will try to make all of the slides available online.

Also, if there is interest in a Chromium User's Meeting/BOF following 
the workshop, which already includes lots of information on Chromium, 
please let us know.

We hope to see you there.

-Mike Houston

[Chromium-dev] Fwd: Off screen GLX rendering is here

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

I caught this message on Apple's X11 mailing list.  I thought there was
a possibility that it might have some relevance for Chromium on Darwin.

-Sean

----- Forwarded message from "Torrey T. Lyons" <to...@XF...> -----

Date: Thu, 02 Sep 2004 16:58:27 -0700
From: "Torrey T. Lyons" <to...@XF...>
Subject: Off screen GLX rendering is here
To: x11...@li...

One of the common complaints about Apple's X11 is that is does not 
allow off screen GLX rendering. I realized recently that there is a 
little known secret about XDarwin that allows off screen GLX 
rendering, while still maintaining super fast direct rendering. In 
its standard configuration XDarwin also does not allow off screen 
rendering but its back end GLX renderer can be changed.

Note: This will not work with Apple's X11. You can only get super 
fast direct rendering and off screen rendering with XFree86 4.4.0 or 
newer or X.Org X11R6.7 or newer on Mac OS X 10.3.x.

The trick is to use the following command in the Terminal and then 
restart XDarwin:

defaults write org.xfree86.XDarwin UseAGLforGLX 0

If this works the XDarwin startup info (normally written to the 
console) will have the line:

Loading GLX bundle glxMesa.bundle (using Mesa)

In this case Mesa will be used for all indirect GLX rendering instead 
of CGL. The advantage of doing this is that Mesa fully supports off 
screen rendering. At the same time most all on screen rendering will 
still be done with the superfast direct rendering you are used to 
with Apple's X11.

The price you pay for this is that any indirect rendering (from 
clients on other computers for example) will be much slower. 
Operating in this "split personality" mode has also not been well 
tested. I might expect some artifacts when resizing windows with GL 
contexts, but so far I have not found any. YMMV.

--Torrey
_______________________________________________
x11-users mailing list | x11...@li...
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/x11-users
Do not post admin requests to the list. They will be ignored.

----- End forwarded message -----

-Sean

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

Re: [Chromium-dev] Chromium start-up time

[Joel W. <we...@st...>]

I agree that Brian's suggestion is an excellent one.  Most Chromium users
are on local networks; they shouldn't be burdened by the minority that
need this capability.

At the time I did convince myself that the call to fqdn() was necessary, 
but I'm afraid I can't recall the circumstances that led me to that.  I do 
recall that earlier in its life Chromium tended to get confused when one 
client referred to a machine by local hostname and another referred to it 
by fqdn.  I *think* the reasoning was that when names were matched, the
full fqdn was needed to make sure the matching worked out.

-Joel

On Thu, 2 Sep 2004 aac...@ad... wrote:
> 
> Hello,
> 
> Yes, I figured it was trying to access a non-local network.  I asked because someone was trying to tell me that it was unnecessary for Chromium to try to qualify the hostnames, that the router would take care of that automatically.
> 
> Brian's idea for adding the 'qualify-hostnames' as a configuration option sounds like a good idea.
> 
> Alicia
> 
> 
> 
> > From: Brian Paul <bri...@tu...>
> > Date: 2004/09/02 Thu PM 12:22:50 EDT
> > To: chr...@li...
> > Subject: Re: [Chromium-dev] Chromium start-up time
> > 
> > Brian Paul wrote:
> > ...
> > If the fqdn() hostname lookup is a real problem, perhaps we could add 
> > a configuration option to enable/disable it.  Something like:
> > 
> > 	cr = CR()
> > 	cr.Conf("fully_qualify_domain_names", 0)
> > 
> > 
> > -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=5047&alloc_id=10808&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=5047&alloc_id=10808&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 

Re: [Chromium-dev] Chromium start-up time

[<aac...@ad...>]

Hello,

Yes, I figured it was trying to access a non-local network.  I asked because someone was trying to tell me that it was unnecessary for Chromium to try to qualify the hostnames, that the router would take care of that automatically.

Brian's idea for adding the 'qualify-hostnames' as a configuration option sounds like a good idea.

Alicia



> From: Brian Paul <bri...@tu...>
> Date: 2004/09/02 Thu PM 12:22:50 EDT
> To: chr...@li...
> Subject: Re: [Chromium-dev] Chromium start-up time
> 
> Brian Paul wrote:
> > aac...@ad... wrote:
> > 
> >> Hi,
> >>
> >> We currently have a 20 node display that we use with Chromium.  All 20 
> >> nodes, including the Mothership and CRAppfaker run on Windows through 
> >> Cygwin. 
> >> I won't go into excruciating detail about our configuration except to 
> >> say that we use one TileSort spu and 20 render spu's, that are added 
> >> and configured through their appropriate nodes.
> >>
> >> The problem we noticed is that the start-up time to initialize all 20 
> >> displays, plus the CRAppfaker with the Mothership was extremely slow, 
> >> taking more than 3 minutes execution time.
> >>
> >> I traced at least part of the problem down to the Mothership.py file 
> >> and the __qualifyHostname__ function.  It was spending 4.5 seconds to 
> >> sit on the call to socket.getfqdn(host).  We did not have DNS set up 
> >> so I believe it was sitting on this call to fully qualify the host 
> >> name and timing out after 4-4.5 seconds.  Also, this function was 
> >> being called twice per display node via the do_acceptrequest and 
> >> do_connectrequest functions.  Therefore, this was adding alot of time 
> >> to wait for all of the displays to initialize.  Could you please 
> >> explain why it needs to fully qualify the name??  I'm not sure I 
> >> understand why it needs to do this since if we just return immediately 
> >> with the hostname that is passed in, it works just fine. 
> >> Thanks,
> >> Alicia
> > 
> > 
> > It looks like that code was a patch from Joel Welling that I checked in 
> > last December.
> > 
> > Maybe Joel can provide some info.
> 
> Joel replied and asked that I forward this info to the list:
> 
> 
> 
> > Well, __qualifyHostname__() does a table lookup, which should be quite fast.  
> > If it fails to find the hostname in that list (__hostPrefixPairs__) it does a 
> > socket.getfqdn(host).  I had to add the lookup to facilitate connecting to 
> > Argonne's vis nodes from outside.  I believe the socket.getfqdn() was in the 
> > server logic before my mod, but not separated off into the 
> > __qualifyHostname__() function.
> > 
> > The cost of taking out the socket.getfqdn() would be that we'd be making 
> > connections based on local domain names instead of global ones, and that would 
> > surely not be good for non-local Chromium networks.  I presume it works fine 
> > for Alicia without the fqdn is that her network is local and all her hosts are 
> > in each other's /etc/hosts tables (or the Windows equivalent).
> > 
> > I remember some discussion about this a while back, but I don't have time at 
> > the moment to search the archives for it.  Alicia, if you don't want to 
> > disable the socket.getfqdn(host) code and if your hostnames have a common 
> > prefix like 'vis', you could add them to __hostPrefixPairs__ as a temporary 
> > work-around.
> 
> 
> If the fqdn() hostname lookup is a real problem, perhaps we could add 
> a configuration option to enable/disable it.  Something like:
> 
> 	cr = CR()
> 	cr.Conf("fully_qualify_domain_names", 0)
> 
> 
> -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=5047&alloc_id=10808&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 

Re: [Chromium-dev] Chromium start-up time

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

Brian Paul wrote:
> aac...@ad... wrote:
> 
>> Hi,
>>
>> We currently have a 20 node display that we use with Chromium.  All 20 
>> nodes, including the Mothership and CRAppfaker run on Windows through 
>> Cygwin. 
>> I won't go into excruciating detail about our configuration except to 
>> say that we use one TileSort spu and 20 render spu's, that are added 
>> and configured through their appropriate nodes.
>>
>> The problem we noticed is that the start-up time to initialize all 20 
>> displays, plus the CRAppfaker with the Mothership was extremely slow, 
>> taking more than 3 minutes execution time.
>>
>> I traced at least part of the problem down to the Mothership.py file 
>> and the __qualifyHostname__ function.  It was spending 4.5 seconds to 
>> sit on the call to socket.getfqdn(host).  We did not have DNS set up 
>> so I believe it was sitting on this call to fully qualify the host 
>> name and timing out after 4-4.5 seconds.  Also, this function was 
>> being called twice per display node via the do_acceptrequest and 
>> do_connectrequest functions.  Therefore, this was adding alot of time 
>> to wait for all of the displays to initialize.  Could you please 
>> explain why it needs to fully qualify the name??  I'm not sure I 
>> understand why it needs to do this since if we just return immediately 
>> with the hostname that is passed in, it works just fine. 
>> Thanks,
>> Alicia
> 
> 
> It looks like that code was a patch from Joel Welling that I checked in 
> last December.
> 
> Maybe Joel can provide some info.

Joel replied and asked that I forward this info to the list:



> Well, __qualifyHostname__() does a table lookup, which should be quite fast.  
> If it fails to find the hostname in that list (__hostPrefixPairs__) it does a 
> socket.getfqdn(host).  I had to add the lookup to facilitate connecting to 
> Argonne's vis nodes from outside.  I believe the socket.getfqdn() was in the 
> server logic before my mod, but not separated off into the 
> __qualifyHostname__() function.
> 
> The cost of taking out the socket.getfqdn() would be that we'd be making 
> connections based on local domain names instead of global ones, and that would 
> surely not be good for non-local Chromium networks.  I presume it works fine 
> for Alicia without the fqdn is that her network is local and all her hosts are 
> in each other's /etc/hosts tables (or the Windows equivalent).
> 
> I remember some discussion about this a while back, but I don't have time at 
> the moment to search the archives for it.  Alicia, if you don't want to 
> disable the socket.getfqdn(host) code and if your hostnames have a common 
> prefix like 'vis', you could add them to __hostPrefixPairs__ as a temporary 
> work-around.


If the fqdn() hostname lookup is a real problem, perhaps we could add 
a configuration option to enable/disable it.  Something like:

	cr = CR()
	cr.Conf("fully_qualify_domain_names", 0)


-Brian

Re: [Chromium-dev] Chromium start-up time

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

aac...@ad... wrote:
> Hi,
> 
> We currently have a 20 node display that we use with Chromium.  All 20 nodes, including the Mothership and CRAppfaker run on Windows through Cygwin.  
> 
> I won't go into excruciating detail about our configuration except to say that we use one TileSort spu and 20 render spu's, that are added and configured through their appropriate nodes.
> 
> The problem we noticed is that the start-up time to initialize all 20 displays, plus the CRAppfaker with the Mothership was extremely slow, taking more than 3 minutes execution time.
> 
> I traced at least part of the problem down to the Mothership.py file and the __qualifyHostname__ function.  It was spending 4.5 seconds to sit on the call to socket.getfqdn(host).  We did not have DNS set up so I believe it was sitting on this call to fully qualify the host name and timing out after 4-4.5 seconds.  Also, this function was being called twice per display node via the do_acceptrequest and do_connectrequest functions.  Therefore, this was adding alot of time to wait for all of the displays to initialize.  Could you please explain why it needs to fully qualify the name??  I'm not sure I understand why it needs to do this since if we just return immediately with the hostname that is passed in, it works just fine.  
> 
> Thanks,
> Alicia

It looks like that code was a patch from Joel Welling that I checked 
in last December.

Maybe Joel can provide some info.

-Brian

[Chromium-dev] Chromium start-up time

[<aac...@ad...>]

Hi,

We currently have a 20 node display that we use with Chromium.  All 20 nodes, including the Mothership and CRAppfaker run on Windows through Cygwin.  

I won't go into excruciating detail about our configuration except to say that we use one TileSort spu and 20 render spu's, that are added and configured through their appropriate nodes.

The problem we noticed is that the start-up time to initialize all 20 displays, plus the CRAppfaker with the Mothership was extremely slow, taking more than 3 minutes execution time.

I traced at least part of the problem down to the Mothership.py file and the __qualifyHostname__ function.  It was spending 4.5 seconds to sit on the call to socket.getfqdn(host).  We did not have DNS set up so I believe it was sitting on this call to fully qualify the host name and timing out after 4-4.5 seconds.  Also, this function was being called twice per display node via the do_acceptrequest and do_connectrequest functions.  Therefore, this was adding alot of time to wait for all of the displays to initialize.  Could you please explain why it needs to fully qualify the name??  I'm not sure I understand why it needs to do this since if we just return immediately with the hostname that is passed in, it works just fine.  

Thanks,
Alicia

[Chromium-dev] Fixed bounding box problems in readback/binaryswap

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

Back in June I mentioned that the bounding box code in the readback 
and binaryswap SPUs was broken.  Basically, only the last 
user-specified bounding box was being used to compute the screen-space 
bounds of the rendering (all previous ones were effectively ignored).

Now there's a bboxUnion field in the WindowInfo struct that keeps 
track of the window-space union of all bounding boxes specified during 
a frame.  That bounding box is then used during compositing.

I also updated the psubmit.c and spheres.c demos to specify bounding 
boxes when the -bbox option is given.  Things appear to be working 
correctly now.

-Brian

Re: [Chromium-dev] seethrough SPU and documents

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

Anthony Steed wrote:
> 
> I've been lurking on this list for a while - we've been using Chromium 
> for a while for some demos and prototyping some systems for driving a CAVE.
> 
> Because of the experience of a student, I took a look at the online 
> documentation. The online and CVS documentation for the seethrough 
> example is out of date (the state tracker code was wrong, some code 
> typos). I had a go at updating it and it almost works as advertised now.
> 
> First things first: in template/gen_template.py, the file 
> templatespu_proto.py doesn't exist, so the generation scripts fails. 
> That line needs deleting.
> 
> In the seethrough example, I fixed all the problems with changed data 
> structures and code, but I can't get my quake3 to look like glassquake 
> unless I force multitexturing to be off. I.E. in q3config.cfg, change:
> 
>  seta r_ext_multitexture "1"
> to
>  seta r_ext_multitexture "0"
> 
> I had a quick go at getting the multitexturing working, but someone who 
> knows more about chromium could probably spot the problem straight away. 
> Otherwise it works fine.
> 
> As I'm not registered as a developer on sourceforge, I put a revised 
> version of the codegen.html here:
>  http://www.cs.ucl.ac.uk/staff/A.Steed/scratch/cr/codegen.html
> and code packages here:
>  http://www.cs.ucl.ac.uk/staff/A.Steed/scratch/cr/seethrough.tar.gz
>  http://www.cs.ucl.ac.uk/staff/A.Steed/scratch/cr/seethrough_step11.tar.gz

Anthony,

I've checked in your updated docs, and did some other updates myself.

I've run out of time to investigate the multitexture issue though.

-Brian

Re: [Chromium-dev] Asymmetric display configuration?

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

Randy Groves wrote:
> We've got a 3x3 display wall with several of the displays driven by 
> dual-head NVIDIA Quadro FX 2000 cards.  9 displays, 5 PCs, 5 cards.  We 
> can get DMX to run on a configuration where all but one of the displays 
> is on a dual-head card.  DMX has no problem working with the X displays 
> :0.0 and :0.1 on each of the dual head machines.  So far, we have not 
> succeeded in getting chromium to do the same thing.
> 
> So we modified some of the dual heads to use twinview, so the display is 
> only :0.0, and chromium will run on top of DMX in this configuration.  
> But the twinview only seems to work if all the twin views are in the 
> same configuration - below, rightof, etc.  In this case we've set up the 
> bottom 6 in a 3x1 twinview format (using the 'Below' setting).   But 
> that leaves the remaining 3 displays.  We would like to  use the 
> remaining two machines to cover these last three displays, but that 
> means that one would be a single display, and the remaining two would be 
> in twinview but with a 'RightOf' setting.
> 
> DMX has no problem with this configuration.  But, so far, we haven't 
> found a way to get chromium to run on this configuration.  We are using 
> modifications of the dmx.conf file.

What are the symptoms of Chromium not working?


> So - the question is - does chromium support asymmetric display 
> configurations like the one we'd like to create?  Is it just a matter of 
> getting the right hand-crafted configuration file set up?  Or is this 
> just too much of a burden for chromium's mind?

This sort of thing should work.  Without knowing more, about the only 
thing that comes to mind is to change the tilesort's bucket_mode like 
this:

tilesortspu.Conf('bucket_mode', 'Test All Tiles')

-Brian

[Chromium-dev] Asymmetric display configuration?

[Randy G. <ran...@bo...>]

We've got a 3x3 display wall with several of the displays driven by 
dual-head NVIDIA Quadro FX 2000 cards.  9 displays, 5 PCs, 5 cards.  We can 
get DMX to run on a configuration where all but one of the displays is on a 
dual-head card.  DMX has no problem working with the X displays :0.0 and 
:0.1 on each of the dual head machines.  So far, we have not succeeded in 
getting chromium to do the same thing.

So we modified some of the dual heads to use twinview, so the display is 
only :0.0, and chromium will run on top of DMX in this configuration.  But 
the twinview only seems to work if all the twin views are in the same 
configuration - below, rightof, etc.  In this case we've set up the bottom 
6 in a 3x1 twinview format (using the 'Below' setting).   But that leaves 
the remaining 3 displays.  We would like to  use the remaining two machines 
to cover these last three displays, but that means that one would be a 
single display, and the remaining two would be in twinview but with a 
'RightOf' setting.

DMX has no problem with this configuration.  But, so far, we haven't found 
a way to get chromium to run on this configuration.  We are using 
modifications of the dmx.conf file.

So - the question is - does chromium support asymmetric display 
configurations like the one we'd like to create?  Is it just a matter of 
getting the right hand-crafted configuration file set up?  Or is this just 
too much of a burden for chromium's mind?

-randy