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

Re: [Chromium-users] Re: [Chromium-dev] Chromium 1.9 second release candidate

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

Eric Sandall wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On Wed, 24 May 2006, Brian Paul wrote:
>=20
>> Brian Paul wrote:
>>
>>>
>>> A second release candidate of Chromium 1.9 is ready at=20
>>> http://chromium.sf.net/beta
>>>
>>> This just accumulates a few more bugs fixes since the first RC.
>>
>>
>> I haven't seen any feedback on this, positive or negative.
>>
>> It would be good to at least have a couple people confirm that they're=
=20
>> tried it and it's OK.
>=20
>=20
> After applying all patches for initialization posted so far and even
> with removing '-Werror' from configs/Linux.mk, I get this error
> (though it did not show up earlier when I successfully built cr 1.9rc2
> earlier):
> Compiling tsfuncs.c
> tsfuncs.c: In function =91ts_CreateContext=92:
> tsfuncs.c:554: error: too few arguments to function
> =91tab->CreateContext=92
> tsfuncs.c: At top level:
> tsfuncs.c:3726: warning: initialization from incompatible pointer type
> tsfuncs.c: In function =91ts_CreateContext=92:
> tsfuncs.c:555: warning: control reaches end of non-void function
> gmake[2]: *** [../built/crfaker/Linux/tsfuncs.o] Error 1
> gmake[1]: *** [dep] Error 2
> make: *** [opengl_stub.subdir] Error 2
>=20
> gcc 4.1.0-3 on Fedora Core 5. I've tried a 'clean' cr-1.9rc2 build
> with only removing '-Werror' from CXXFLAGS and CFLAGS in
> configs/Linux.mk and still receive the above.
>=20
> I found the difference. If I set "THREADSAFE=3D1" in options.mk I get
> the above error, but if I leave "THREADSAFE=3D0" in options.mk
> cr-1.9rc2 compiles fine.

Try removing the opengl_stub/tsfuncs.c file.  It should get=20
regenerated by the tsfuncs.py script.  It looks like the .c file was=20
accidentally included in the tarball.

-Brian

Re: [Chromium-users] Re: [Chromium-dev] Chromium 1.9 second release candidate

[Eric S. <er...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 24 May 2006, Brian Paul wrote:
> Brian Paul wrote:
>>=20
>> A second release candidate of Chromium 1.9 is ready at=20
>> http://chromium.sf.net/beta
>>=20
>> This just accumulates a few more bugs fixes since the first RC.
>
> I haven't seen any feedback on this, positive or negative.
>
> It would be good to at least have a couple people confirm that they're tr=
ied=20
> it and it's OK.

After applying all patches for initialization posted so far and even
with removing '-Werror' from configs/Linux.mk, I get this error
(though it did not show up earlier when I successfully built cr 1.9rc2
earlier):
Compiling tsfuncs.c
tsfuncs.c: In function =E2=80=98ts_CreateContext=E2=80=99:
tsfuncs.c:554: error: too few arguments to function
=E2=80=98tab->CreateContext=E2=80=99
tsfuncs.c: At top level:
tsfuncs.c:3726: warning: initialization from incompatible pointer type
tsfuncs.c: In function =E2=80=98ts_CreateContext=E2=80=99:
tsfuncs.c:555: warning: control reaches end of non-void function
gmake[2]: *** [../built/crfaker/Linux/tsfuncs.o] Error 1
gmake[1]: *** [dep] Error 2
make: *** [opengl_stub.subdir] Error 2

gcc 4.1.0-3 on Fedora Core 5. I've tried a 'clean' cr-1.9rc2 build
with only removing '-Werror' from CXXFLAGS and CFLAGS in
configs/Linux.mk and still receive the above.

I found the difference. If I set "THREADSAFE=3D1" in options.mk I get
the above error, but if I leave "THREADSAFE=3D0" in options.mk
cr-1.9rc2 compiles fine.

- -sandalle

- --
Eric Sandall                     |  Source Mage GNU/Linux Developer
er...@sa...                  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEdNaYHXt9dKjv3WERApuHAJ9tg69a9iPoDUaNN3LYSC5qbbtWwwCgwHqE
ItzsZTZTfznbv3wXd2eTQmE=3D
=3Dm0eg
-----END PGP SIGNATURE-----

Re: [Chromium-users] Re: [Chromium-dev] Chromium 1.9 second release candidate

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

Michael Barnes wrote:
> All,
> 
> I may have a better patch attached.  If -Werror is needed for building
> cromium, then it might be better just to shut up gcc's bogus warning
> about something that "may be used unitialized".  The flag that shuts
> this up is -Wno-uninitialized.
> 
>>From gcc's manpage:
> 
>       These warnings are made optional because GNU CC is not smart
>       enough to see all the reasons why the code might be correct
>       despite appearing to have an error.

Which version of gcc is that?  I checked the manual for a few versions 
and can't find it.


> Uninitialized variables are bugs.  Warnings about them maybe being
> uninitilized being turned into errors, when they are not unitialized,
> is a waste of our time.
> 
> Please consider the attached patch.
> 
> The patch is against 1.8, but it should apply cleanly to 1.9.

I'm thinking the simplest thing will be to only use -Werror for debug 
builds, as someone previously mentioned.

-Brian

Re: [Chromium-users] Re: [Chromium-dev] Chromium 1.9 second release candidate

[Eric S. <er...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 24 May 2006, Michael Barnes wrote:
> All,
>
> I may have a better patch attached.  If -Werror is needed for building
> cromium, then it might be better just to shut up gcc's bogus warning
> about something that "may be used unitialized".  The flag that shuts
> this up is -Wno-uninitialized.

IMO release code shouldn't use -Werror. ;)

>> From gcc's manpage:
>
>      These warnings are made optional because GNU CC is not smart
>      enough to see all the reasons why the code might be correct
>      despite appearing to have an error.
>
> Uninitialized variables are bugs.  Warnings about them maybe being
> uninitilized being turned into errors, when they are not unitialized,
> is a waste of our time.
>
> Please consider the attached patch.
>
> The patch is against 1.8, but it should apply cleanly to 1.9.
<snip>

This may do better as I ran into another uninitialized error while
compiling 1.9rc2:

Rebuilding dependencies for wetspu_init.c
Compiling wetspu.c
cc1: warnings being treated as errors
wetspu.c: In function =E2=80=98ComputeNormal=E2=80=99:
wetspu.c:128: warning: =E2=80=98p1[2]=E2=80=99 may be used uninitialized in
this function
wetspu.c:128: warning: =E2=80=98p2[2]=E2=80=99 may be used uninitialized in
this function
wetspu.c:128: warning: =E2=80=98p3[2]=E2=80=99 may be used uninitialized in
this function
wetspu.c:128: warning: =E2=80=98p4[2]=E2=80=99 may be used uninitialized in
this function
gmake[3]: *** [../../built/wetspu/Linux/wetspu.o] Error 1
gmake[2]: *** [dep] Error 2
gmake[1]: *** [wet.subdir] Error 2
make: *** [spu.subdir] Error 2

Possibly more if I fix this one and let the compile continue. In case
we are wanting to initialize everything, a patch is attached.

- -sandalle

- --
Eric Sandall                     |  Source Mage GNU/Linux Developer
er...@sa...                  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEdNDZHXt9dKjv3WERAsVJAJ0cLf51I6PR/TXUmBxm+YL8V/F7LgCdGivF
APIugkUU0yCTO4vbOysQpNc=3D
=3DeUhr
-----END PGP SIGNATURE-----

Re: [Chromium-users] Re: [Chromium-dev] Chromium 1.9 second release candidate

[Eric S. <er...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 24 May 2006, Brian Paul wrote:
> Eric Sandall wrote:
>> On Wed, 24 May 2006, Brian Paul wrote:
>>> Brian Paul wrote:
>>>> A second release candidate of Chromium 1.9 is ready at
>>>> http://chromium.sf.net/beta
>>>>=20
>>>> This just accumulates a few more bugs fixes since the first RC.
>>>=20
>>> I haven't seen any feedback on this, positive or negative.
>>>=20
>>> It would be good to at least have a couple people confirm that they're=
=20
>>> tried
>>> it and it's OK.
>>>=20
>>> Thanks.
>>=20
>> Trying to compile cr-1.9rc2 gives:
>> $ make
>> ...
>> Compiling state_program.c
>> cc1: warnings being treated as errors
>> state_program.c: In function =91crStateGetVertexAttribivNV=92:
>> state_program.c:1042: warning: =91floatParams[0]=92 is used
>> uninitialized in this function
>> state_program.c:1040: warning: =91floatParams[1]=92 may be used
>> uninitialized in this function
>> state_program.c:1040: warning: =91floatParams[2]=92 may be used
>> uninitialized in this function
>> state_program.c:1040: warning: =91floatParams[3]=92 may be used
>> uninitialized in this function
>> gmake[2]: *** [../built/crstate/Linux/state_program.o] Error 1
>> gmake[1]: *** [dep] Error 2
>> make: *** [state_tracker.subdir] Error 2
>>=20
>> This is with gcc 4.1.0-3 on Fedora Core 5. If I remove -Werror from
>> configs/Linux.mk CXXFLAGS and CFLAGS cr-1.9rc2 compiles (I have not
>> tried running it yet).
>
> OK, I actually fixed the same problem in a different function and didn't=
=20
> realize there was a second instance of it.
>
> The patch is attached.

Still gives:
Rebuilding dependencies for state_program.c
Compiling state_program.c
cc1: warnings being treated as errors
state_program.c: In function =E2=80=98crStateGetVertexAttribivARB=E2=80=99:
state_program.c:1099: warning: =E2=80=98floatParams[0]=E2=80=99 is used
uninitialized in this function
state_program.c:1097: warning: =E2=80=98floatParams[1]=E2=80=99 may be used
uninitialized in this function
state_program.c:1097: warning: =E2=80=98floatParams[2]=E2=80=99 may be used
uninitialized in this function
state_program.c:1097: warning: =E2=80=98floatParams[3]=E2=80=99 may be used
uninitialized in this function
gmake[2]: *** [../built/crstate/Linux/state_program.o] Error 1
gmake[1]: *** [dep] Error 2
make: *** [state_tracker.subdir] Error 2

And again when the above is fixed:
Rebuilding dependencies for state_program.c
Compiling state_program.c
cc1: warnings being treated as errors
state_program.c: In function =E2=80=98crStateGetVertexAttribdvARB=E2=80=99:
state_program.c:1113: warning: =E2=80=98floatParams[0]=E2=80=99 is used
uninitialized in this function
state_program.c:1111: warning: =E2=80=98floatParams[1]=E2=80=99 may be used
uninitialized in this function
state_program.c:1111: warning: =E2=80=98floatParams[2]=E2=80=99 may be used
uninitialized in this function
state_program.c:1111: warning: =E2=80=98floatParams[3]=E2=80=99 may be used
uninitialized in this function
gmake[2]: *** [../built/crstate/Linux/state_program.o] Error 1
gmake[1]: *** [dep] Error 2
make: *** [state_tracker.subdir] Error 2

Seems to be fixed in CVS. Attached is a patch (after applying yours)
that fixes the other two locations.

- -sandalle

- --
Eric Sandall                     |  Source Mage GNU/Linux Developer
er...@sa...                  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEdL/THXt9dKjv3WERAgeAAJ9RfL1vAsDNGxiJ/1C3HJ9RVIdgeQCfbCNG
GAsQAuWsKhyTqe7KW3io7kY=3D
=3Dwh1q
-----END PGP SIGNATURE-----

Re: [Chromium-users] Re: [Chromium-dev] Chromium 1.9 second release candidate

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

Eric Sandall wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On Wed, 24 May 2006, Brian Paul wrote:
>=20
>> Brian Paul wrote:
>>
>>>
>>> A second release candidate of Chromium 1.9 is ready at
>>> http://chromium.sf.net/beta
>>>
>>> This just accumulates a few more bugs fixes since the first RC.
>>
>>
>> I haven't seen any feedback on this, positive or negative.
>>
>> It would be good to at least have a couple people confirm that they're=
=20
>> tried
>> it and it's OK.
>>
>> Thanks.
>=20
>=20
> Trying to compile cr-1.9rc2 gives:
> $ make
> ...
> Compiling state_program.c
> cc1: warnings being treated as errors
> state_program.c: In function =91crStateGetVertexAttribivNV=92:
> state_program.c:1042: warning: =91floatParams[0]=92 is used
> uninitialized in this function
> state_program.c:1040: warning: =91floatParams[1]=92 may be used
> uninitialized in this function
> state_program.c:1040: warning: =91floatParams[2]=92 may be used
> uninitialized in this function
> state_program.c:1040: warning: =91floatParams[3]=92 may be used
> uninitialized in this function
> gmake[2]: *** [../built/crstate/Linux/state_program.o] Error 1
> gmake[1]: *** [dep] Error 2
> make: *** [state_tracker.subdir] Error 2
>=20
> This is with gcc 4.1.0-3 on Fedora Core 5. If I remove -Werror from
> configs/Linux.mk CXXFLAGS and CFLAGS cr-1.9rc2 compiles (I have not
> tried running it yet).

OK, I actually fixed the same problem in a different function and=20
didn't realize there was a second instance of it.

The patch is attached.

-Brian

Re: [Chromium-users] Re: [Chromium-dev] Chromium 1.9 second release candidate

[Eric S. <er...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 24 May 2006, Brian Paul wrote:
> Brian Paul wrote:
>>
>> A second release candidate of Chromium 1.9 is ready at
>> http://chromium.sf.net/beta
>>
>> This just accumulates a few more bugs fixes since the first RC.
>
> I haven't seen any feedback on this, positive or negative.
>
> It would be good to at least have a couple people confirm that they're tr=
ied
> it and it's OK.
>
> Thanks.

Trying to compile cr-1.9rc2 gives:
$ make
=2E..
Compiling state_program.c
cc1: warnings being treated as errors
state_program.c: In function =E2=80=98crStateGetVertexAttribivNV=E2=80=99:
state_program.c:1042: warning: =E2=80=98floatParams[0]=E2=80=99 is used
uninitialized in this function
state_program.c:1040: warning: =E2=80=98floatParams[1]=E2=80=99 may be used
uninitialized in this function
state_program.c:1040: warning: =E2=80=98floatParams[2]=E2=80=99 may be used
uninitialized in this function
state_program.c:1040: warning: =E2=80=98floatParams[3]=E2=80=99 may be used
uninitialized in this function
gmake[2]: *** [../built/crstate/Linux/state_program.o] Error 1
gmake[1]: *** [dep] Error 2
make: *** [state_tracker.subdir] Error 2

This is with gcc 4.1.0-3 on Fedora Core 5. If I remove -Werror from
configs/Linux.mk CXXFLAGS and CFLAGS cr-1.9rc2 compiles (I have not
tried running it yet).

- -sandalle

- --
Eric Sandall                     |  Source Mage GNU/Linux Developer
er...@sa...                  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEdLHXHXt9dKjv3WERAqD4AJ96CWbDTQNe8FajqDBCHRv0LgjORQCeLaAq
JQ0D/nw6DoIAN1fzjGWtvLQ=3D
=3Dr0FJ
-----END PGP SIGNATURE-----

Re: [Chromium-dev] Chromium 1.9 second release candidate

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

Brian Paul wrote:

> Brian Paul wrote:
>
>>
>> A second release candidate of Chromium 1.9 is ready at 
>> http://chromium.sf.net/beta
>>
>> This just accumulates a few more bugs fixes since the first RC.
>
>
> I haven't seen any feedback on this, positive or negative.
>
> It would be good to at least have a couple people confirm that they're 
> tried it and it's OK.
>
> Thanks. 

I have yet to try and build/test 1.9 on OSX, but I will get to that 
tomorrow morning.

 -Chris

Re: [Chromium-dev] Chromium 1.9 second release candidate

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

Brian Paul wrote:
> 
> A second release candidate of Chromium 1.9 is ready at 
> http://chromium.sf.net/beta
> 
> This just accumulates a few more bugs fixes since the first RC.

I haven't seen any feedback on this, positive or negative.

It would be good to at least have a couple people confirm that they're 
tried it and it's OK.

Thanks.

-Brian

[Chromium-dev] Chromium 1.9 second release candidate

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

A second release candidate of Chromium 1.9 is ready at 
http://chromium.sf.net/beta

This just accumulates a few more bugs fixes since the first RC.

-Brian

Re: [Chromium-dev] Patch for building on Windows

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

Michael D=FCrig wrote:
>=20
> The following patch is required to build on Windows.

Thanks.  Fixed in CVS.

-Brian

Re: [Chromium-dev] SourceForge CVS changes

[Sean A. <ah...@or...>]

I haven't tried it, but wouldn't this work as a one-liner?

     % find . -name Root -print | perl -pi.bak -e 's/cvs/chromium.cvs/g'

-Sean

--
Sean Ahern
Oak Ridge National Laboratory


On May 16, 2006, at 11:07 AM, Robert Ellison wrote:
>> If you want to update all the CVS/Root files in your current CVS  
>> tree, replace the old hostname:
>>     cvs.sourceforge.net
>> with the new one:
>>     chromium.cvs.sourceforge.net
>> Maybe someone handy with shells scripts can post a 'find/sed'  
>> command to do this.
> 	$ cd <chromiumDirectory>
> 	$ cvsmv cvs.sourceforge.net chromium.cvs.sourceforge.net
>
> Bob Ellison
> Self-proclaimed Script Meister
> Tungsten Graphics, Inc.
> #!/bin/bash
> prog=${0##*/}
>
> #
> # Things to do if you catch an interrupt
> #
> trap "rm -f /tmp/$prog$$*" 0
> trap "rm -f /tmp/$prog$$*; exit 2" 1 2 3 15
>
> #
> # Set variables to default values
> #
> verbose=no
> directory=.
> tmpFileList=/tmp/$prog$$A
> tmpEditedFile=/tmp/$prog$$B
>
> #
> # Parse command-line options
> #
>
> options=":hxd:"
> while getopts "$options" arg
> do
>     case "$arg" in
> 	h) {
> 	    echo "Usage: $prog [-${options#:}] /old-cvsroot /new-cvsroot"
> 	    echo "Change all references in CVS/Root files from the old CVS  
> root to the new one"
> 	    echo "-h gives help"
> 	    echo "-x for debug"
> 	    echo "-d specifies directory [$directory]"
> 	    } 1>&2
> 	    exit 1
> 	    ;;
> 	x)  verbose=yes ; set -x ;;
> 	:)  echo "$prog: $OPTARG requires an argument.  Use -h for help."  
> 1>&2
> 	    exit 2
> 	    ;;
> 	*)  {
> 	    echo "$prog: unknown option '$OPTARG'.  Use -h for help."
> 	    } 1>&2
> 	    exit 2
>     esac
> done
> shift $(($OPTIND - 1))
>
> if [ $# -ne 2 ]; then
>     echo "$prog: need exactly 2 arguments.  Use -h for help." 1>&2
>     exit 2
> fi
>
> # Get all the files that refer to the old CVS root
> find $directory -path '*CVS/Root' | xargs grep -l $1 > $tmpFileList
>
> # Edit them one at a time.
> cat $tmpFileList | while read file; do
>     sed -e "s%$1%$2%g" < $file > $tmpEditedFile
>     mv $tmpEditedFile $file
> done
>
>
> exit 0

Re: [Chromium-dev] SourceForge CVS changes

[Robert E. <pa...@tu...>]

> If you want to update all the CVS/Root files in your current CVS tree, 
> replace the old hostname:
> 
>     cvs.sourceforge.net
> 
> with the new one:
> 
>     chromium.cvs.sourceforge.net
> 
> Maybe someone handy with shells scripts can post a 'find/sed' command to 
> do this.
	$ cd <chromiumDirectory>
	$ cvsmv cvs.sourceforge.net chromium.cvs.sourceforge.net

Bob Ellison
Self-proclaimed Script Meister
Tungsten Graphics, Inc.

[Chromium-dev] Patch for building on Windows

[<dr...@bf...>]

The following patch is required to build on Windows.

Michael

[Chromium-dev] SourceForge CVS changes

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

SourceForge has had a lot of CVS problems recently.  As of today, it's 
supposed to be functioning again.

There's been some changes though.  You'll either have to check out a 
fresh CVS tree (using the new CVS repository name) or update all the 
CVS/Root files in your current Chromium tree.

The updated CVS info is here:  http://sourceforge.net/cvs/?group_id=16529

If you want to update all the CVS/Root files in your current CVS tree, 
replace the old hostname:

	cvs.sourceforge.net

with the new one:

	chromium.cvs.sourceforge.net

Maybe someone handy with shells scripts can post a 'find/sed' command 
to do this.

-Brian

Re: [Chromium-dev] Error in stereo.conf

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

Michael D=FCrig wrote:
>=20
> Regarding the stereo*.conf files which come along with Chromium I think=
=20
> there is an error in the calculation of the viewing frustum.
> Shouldn't it be
>=20
> # Projection matrix
> p =3D crmatrix.CRMatrix()
> if eye =3D=3D 0:
>   left =3D s * ((halfWidth * -aspect) + EyeSep);
>   right =3D s * ((halfWidth * aspect) + EyeSep);
> else:
>   left =3D s * (halfWidth * -aspect - EyeSep);
>   right =3D s * (halfWidth * aspect - EyeSep);
>=20
> instead of
>=20
> # Projection matrix
> p =3D crmatrix.CRMatrix()
> if eye =3D=3D 0:
>   left =3D s * ((halfWidth * -aspect) - EyeSep);
>   right =3D s * ((halfWidth * aspect) - EyeSep);
> else:
>   left =3D s * (halfWidth * -aspect + EyeSep);
>   right =3D s * (halfWidth * aspect + EyeSep);
>=20
>=20
> For the left eye the scene is shifted to the right by EyeSep. This=20
> results in a right shift of the corresponding near plane by s*EyeSep.
>=20
> I verified the above in our CAVE environment by displaying a vertical=20
> line exactly at the focal distance. Moving the line back and forth alon=
g=20
> the z-axis it will always display in negative parallax in the first=20
> case. In the second case however it will correctly display in=20
> negative/positive parallax depending on the z-coordinate being behind/i=
n=20
> front of the focal distance.

That sounds right.  I've checked in your changes.

-Brian

[Chromium-dev] Error in stereo.conf

[<dr...@bf...>]

Regarding the stereo*.conf files which come along with Chromium I think 
there is an error in the calculation of the viewing frustum.
Shouldn't it be

# Projection matrix
p = crmatrix.CRMatrix()
if eye == 0:
   left = s * ((halfWidth * -aspect) + EyeSep);
   right = s * ((halfWidth * aspect) + EyeSep);
else:
   left = s * (halfWidth * -aspect - EyeSep);
   right = s * (halfWidth * aspect - EyeSep);

instead of

# Projection matrix
p = crmatrix.CRMatrix()
if eye == 0:
   left = s * ((halfWidth * -aspect) - EyeSep);
   right = s * ((halfWidth * aspect) - EyeSep);
else:
   left = s * (halfWidth * -aspect + EyeSep);
   right = s * (halfWidth * aspect + EyeSep);


For the left eye the scene is shifted to the right by EyeSep. This 
results in a right shift of the corresponding near plane by s*EyeSep.

I verified the above in our CAVE environment by displaying a vertical 
line exactly at the focal distance. Moving the line back and forth along 
the z-axis it will always display in negative parallax in the first 
case. In the second case however it will correctly display in 
negative/positive parallax depending on the z-coordinate being behind/in 
front of the focal distance.

Michael

[Chromium-dev] Chromium 1.9 release candidate

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

A release candidate of Chromium 1.9 is available at:

http://chromium.sourceforge.net/beta/

The main feature is about a year's worth of bug fixes.  Please give it 
a try and report any problems.

I'm going to be travelling this week and probably won't get back to 
Chromium until Friday.

-Brian

[Chromium-dev] Cr 1.9 prep

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

It's been a year since Cr 1.8 and there's probably a fair number of 
fixes in CVS that should go out.

I think I've got some patches/bug reports in my inbox that I should go 
over.  Anyone else?

I'll try to put together a Cr 1.9 release candidate soon.

-Brian

Re: [Chromium-dev] Re: Source for Cr overhead

[Niraj T. <nt...@gm...>]

On 4/18/06, Brian Paul <bri...@tu...> wrote:
>
> Niraj Tolia wrote:
> > On 4/18/06, *Brian Paul* <bri...@tu...
> > <mailto:bri...@tu...>> wrote:
> >
> >     Niraj Tolia wrote:
> >      > Hi Brian,
> >      >
> >      > We are using fairly recent Cr CVS code for QuakeViz (an
> earthquake
> >      > modeling app from http://www.cs.cmu.edu/~quake/>. Our testing
> right
> >      > should not be stressing a system as we rotate an small model in =
a
> >      > 640x480 window. However, we see a very significant difference in
> the
> >      > nubmer of frames/sec.
> >      >
> >      > Attached is a graph of a particular interactive benchmark.
> >
> >     I don't see an attachment.
> >
> >
> > My apologies. It seems I forgot to attach the PDF. Attached now.
>
> What does the vertical axis (CDF) mean?


The graph is measuring the number of FPS seen for each user input that
generates a screen update. For example, the act of moving your mouse to
rotate an object might generate 60 frames over 3 seconds, or on average, 20
FPS. As we have a very large number of user inputs in this benchmark, we
generate a CDF to figure out what fraction of events deliver 'N' frames per
second.

We ensure that the results are consistent across different scenarios by
using a replay tool for user input.

Niraj

-Brian
>
>


--
http://www.cs.cmu.edu/~ntolia

Re: [Chromium-dev] Re: Source for Cr overhead

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

Niraj Tolia wrote:
> On 4/18/06, *Brian Paul* <bri...@tu... 
> <mailto:bri...@tu...>> wrote:
> 
>     Niraj Tolia wrote:
>      > Hi Brian,
>      >
>      > We are using fairly recent Cr CVS code for QuakeViz (an earthquake
>      > modeling app from http://www.cs.cmu.edu/~quake/>. Our testing right
>      > should not be stressing a system as we rotate an small model in a
>      > 640x480 window. However, we see a very significant difference in the
>      > nubmer of frames/sec.
>      >
>      > Attached is a graph of a particular interactive benchmark.
> 
>     I don't see an attachment.
> 
> 
> My apologies. It seems I forgot to attach the PDF. Attached now.

What does the vertical axis (CDF) mean?

-Brian

[Chromium-dev] Re: Source for Cr overhead

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

Niraj Tolia wrote:
> Hi Brian,
> 
> We are using fairly recent Cr CVS code for QuakeViz (an earthquake 
> modeling app from http://www.cs.cmu.edu/~quake/>. Our testing right 
> should not be stressing a system as we rotate an small model in a 
> 640x480 window. However, we see a very significant difference in the 
> nubmer of frames/sec.
> 
> Attached is a graph of a particular interactive benchmark.

I don't see an attachment.


> Thick is 
> simply running the model on NativeGL (Linux) and measuring the number of 
> glxSwapBuffer() calls. Chromium loopback is using the Cr renderer on the 
> same machine as the application. Do you know why there is suck a stark 
> difference in performance? The overhead of using TCP + GL 
> Marshalling/Unmarshalling? Any thoughts would be helpful.

Going over the network is always a lot slower than the local graphics 
card.  How much slower depends on various factors like the network 
speed itself (no surprise there).

Using display lists is one potential way to increase performance since 
you can draw quite a bit with a few, small glCallList commands.

Another simple thing you can do is run 'top' on the hosts to see if 
any of them are CPU limited.


> PS I kept this email off list for now. However, if you feel it would be 
> helpful to others, feel free to cc the list on the reply.

I'm cc'ing the Chromium dev list in case anyone else has anything to add.

-Brian

Re: [Chromium-dev] Request for CVS tarball

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

Niraj Tolia wrote:
> Anonymous CVS access for Chromium has been down for a number of days now 
> - <http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1 
> <http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1>>. 
> Would it be possible to get a tarball of the current CVS state? 
> Unfortunately, http://cvs.sourceforge.net/cvstarballs/ does not include 
> Chromium.

I'll send you one off-line.

-Brian

[Chromium-dev] Request for CVS tarball

[Niraj T. <nt...@gm...>]

Anonymous CVS access for Chromium has been down for a number of days now - =
<
http://sourceforge.net/docman/display_doc.php?docid=3D2352&group_id=3D1>. W=
ould
it be possible to get a tarball of the current CVS state? Unfortunately,
http://cvs.sourceforge.net/cvstarballs/ does not include Chromium.

Thanks,
Niraj

--
http://www.cs.cmu.edu/~ntolia

Re: [Chromium-dev] [RFC] Patch for VNC SPU getting "stuck"

[Niraj T. <nt...@gm...>]

On 3/1/06, Brian Paul <bri...@tu...> wrote:
>
> Niraj Tolia wrote:
> > This report is against CVS HEAD. With the last round of changes, the
> > Async IO code path will block everytime there is no update to send. The
> > relevant stack trace is
> >
> > #3  0x00a63d75 in crWaitSemaphore (s=3D0xca46b8) at threads.c:259
> > #4  0x00c8786c in vncspuWaitDirtyRects (region=3D0xa246884,
> > frame_num=3D0xa2469e8)
> >     at vncspu.c:335
> > #5  0x00c8b13e in rf_client_updatereq () at client_io.c:516
> > #6  0x00c8989d in aio_process_input (slot=3D0xa246728) at async_io.c:56=
2
> > #7  0x00c89486 in aio_mainloop () at async_io.c:390
> >
> > We never ran into this issue earlier as the VNC SPU had a fixed frame
> > update rate and we would always have something to send out. However, no=
w
> > we can get stuck because of the above. Things that the user runs into
> > includes attempts at new connections "hanging". This happens because we
> > never return to the aio_mainloop unless an update was received from the
> > remote application running under crappfaker.
>
> The CVS HEAD code should work fine for a single VNC viewer, but I can
> see how it would hang with multiple viewers.  I hadn't gotten around
> to fixing that yet.


There are actually unintended consequences for a single viewer too. Say a
single viewer connected, sent a FrameBufferUpdateRequest, received none, an=
d
then disconnected. As far as the client goes, it did a clean shutdown but
the VNC SPU is stuck in the above code path. Now, when a viewer attempts to
reconnect, the new connection will not be accepted till a screen update is
received from the remote end and control is actually returned to the
aio_mainloop().

> As we already record that an update was requested on the current client
> > slot, one option is to return to the aio_mainloop and defer sending the
> > update till something is actually available. The deferred update can be
> > sent by leveraging the s_idle_func used in the AIO code. An example
> > patch of how this could be done is attached. One disadvantage is that w=
e
> > need to reduce the timeout value of the select() call in aio_mainloop()=
.
> > Testing did not indicate any increased CPU usage though as the idle
> > function is cheap.
> >
> > I have a decent handle on the VNC SPU code and so, if you feel this
> > should be done differently, just let me know and I should be able to
> > code up another patch.
>
> Even with your patch, when I attach two VNC viewers, things aren't
> running as expected.  One viewer or the other will freeze up for long
> periods.


I thought this did work but it was a preliminary patch and I was trying to
fix the above single viewer problem that I just outlined above. Let me look
into it and see if I missed something obvious. Let me know if I can help ou=
t
in any other way.

Thanks,
Niraj

I'm looking into it.  I may not have a fix until next week though.
>
> -Brian
>



--
http://www.cs.cmu.edu/~ntolia