mesa3d-dev

Re: [Mesa3d-dev] back to autoconf 2.13

[Brian P. <br...@va...>]

"Sven M. Hallberg" wrote:
> 
> Greetings,
> 
> I have rearranged the configure.in to work with autoconf v2.13 again.
> Unfortunately it is now no longer possible to use configure to compile a Mesa
> with missing GLUT and/or demo source directories. However, one might consider
> making those seperate packages, thus giving them their own configure script...
> But that's another story.

As sophisticated as autoconf is, I'm surprised that you can't
detect whether or not src-glut/, demos/, etc. exist at compile time.


> Anyways, my first show at building died with cpp unable to find
> GL/include/glcore.h, included from glheader.h. I have not been able to find
> that file anywhere, however my old locate db indicated it used to reside
> in the Mesa src/ dir. Am I missing something or is this a bug?

As Keith said, it's in Mesa/include/GL/internal/glcore.h.

-Brian

Re: [Mesa3d-dev] sources.lst files

[Brian P. <br...@va...>]

"Sven M. Hallberg" wrote:
> 
> Again,
> 
> I thought I'd drop a note about this, so nobody trips over it.
> 
> As there is a lot of flux in the list of source files especially in src/
> it's hard to keep track of every file removed/renamed/moved/whatever. I've
> assembled a script gen_srclists.sh in the top source dir that generates a file
> source.lst in every directory which has a Makefile.am with exactly one SOURCES
> directive and an "include sources.lst" line. It fills sources.lst with simply
> a sorted list of all .c and .h file in the respective directory.
> 
> The script is just meant as a hack to quickly create _some_ list of files. If
> that list is not 100% right it can easily be corrected. Further, renaming the
> list file will of course lock the script out.
> 
> Regards,
> Sven
> 
> PS: Maybe we could even modify the "manual" Makefiles to use these list files.
>     That way the need for seperate maintainance of the traditional and the
>     automake lists would disappear. Comments anyone?


The src/Makefile.X11 file is always up to date.  It's what Keith
and I use.  If your scripts will help you that's fine.

-Brian

Re: [Mesa3d-dev] 3.4.1 (small'ish patch).

[Alan H. <aho...@va...>]

On Mon, Feb 12, 2001 at 09:01:31AM -0700, Brian Paul wrote:
> Alan Hourihane wrote:
> > 
> > Brian,
> > 
> > Did you pick up Nathan's fix for gloss (compacted normals) and the SI's
> > libGLU (it's on the trunk DRI branch).
> > 
> > I think that should probably go in 3.4.1. - especially now the SI's libGLU
> > is in the XFree86 tree.
> 
> I had asked Keith about this on Friday.  The Mesa 3.4.1 CVS texgen_tmp.h
> file is still different from the DRI CVS code.  I wasn't sure which is
> the correct version.
> 
> Sounds like the DRI CVS texgen_tmp.h (and texture.c) is the corrected
> code.  Right?
> 
Yep. Nathan should confirm though.

Alan.

Re: [Mesa3d-dev] Texture conversion in 3.4.x?

[Gareth H. <ga...@va...>]

Brian Paul wrote:
> 
> I have no plans for a 3.4.2 release at this time.

Okay.

> I'd suggest adding the new Radeon texture formats to the 3.4.1
> texutil.c code.  That shouldn't be a big job and would be a safe
> modification, I'd think.  I'll probably release 3.4.1 in the next
> 24 hours.  If you don't get the new texel formats into 3.4.1 for
> the release that's no big deal.  The mesa_3_4_branch will still
> exist.

Okay.  They shouldn't take long to add, so I'll look at it later tonight
as an interim measure.

> The ExtractTexel stuff is in 3.5 and will never be back ported
> to 3.4.x.

Agreed.

-- Gareth

Re: [Mesa3d-dev] 3.4.1 (small'ish patch).

[Brian P. <br...@va...>]

Alan Hourihane wrote:
> 
> Brian,
> 
> Did you pick up Nathan's fix for gloss (compacted normals) and the SI's
> libGLU (it's on the trunk DRI branch).
> 
> I think that should probably go in 3.4.1. - especially now the SI's libGLU
> is in the XFree86 tree.

I had asked Keith about this on Friday.  The Mesa 3.4.1 CVS texgen_tmp.h
file is still different from the DRI CVS code.  I wasn't sure which is
the correct version.

Sounds like the DRI CVS texgen_tmp.h (and texture.c) is the corrected
code.  Right?

-Brian

[Mesa3d-dev] 3.4.1 (small'ish patch).

[Alan H. <aho...@va...>]

Brian,

Did you pick up Nathan's fix for gloss (compacted normals) and the SI's
libGLU (it's on the trunk DRI branch).

I think that should probably go in 3.4.1. - especially now the SI's libGLU
is in the XFree86 tree.

Alan.

Re: [Mesa3d-dev] libGLw.a vs libMesaGLw.a vs libMesaGLwM.a?

[Brian P. <br...@va...>]

"Marcelo E. Magallon" wrote:
> 
> Hi,
> 
>  I was updating the Debian package for Mesa and I want to make sure I'm
>  not going to mess up things.  In Debian there are several Mesa packages
>  available: the ones from the mesa source (the "regular" mesa, a glide2
>  package, a ggi package, plus a development package) and the ones coming
>  from the XFree86 sources (the "regular" mesa, xlibmesa3[1], a
>  development package, xlibmesa-dev, and a OSMesa package).  The 3.2
>  packages still have some libMesaGL -> libGL symlinks which I'm going to
>  remove in the 3.4 package (or 3.4.1).  What I'm not sure what to do
>  with is the libMesaGLw library.  The xlibmesa-dev package provides
>  libGLw.a, which contains the following symbol definitions:
> 
>     GLwDrawingAreaMakeCurrent
>     GLwDrawingAreaSwapBuffers
>     glwDrawingAreaClassRec
>     glwDrawingAreaWidgetClass
>     glwMDrawingAreaClassRec
>     glwM1DrawingAreaWidgetClass
>     glwM2DrawingAreaWidgetClass
>     GLwCreateM1DrawingArea
>     GLwCreateM2DrawingArea
>     glwMDrawingAreaClassRec
> 
>  which is slightly different from what's generated using the sources in
>  widgets-mesa.
> 
>  The other difference is the name of the library itself.  mesa generates
>  libMesaGLw and libMesaGLwM, depending if the Motif version of the
>  widgets is enabled or not.  This library also provides the "mesa"
>  functions (e.g., mesaDrawingAreaClassRec).
> 
>  My problem with all of this is that the the "xfree86" packages provide
>  libGLw.a as part of the aforementioned xlibmesa-dev package, which
>  means the mesag-dev[2] package has to provide this file in some
>  (compatible) way.
> 
>  One possible solution for me is to just ask the XFree86 maintainer to
>  split the widgets out of the xlibmesa packages and don't use the ones
>  provided by the mesa source.  The other one is to ask you guys to use
>  the SI source for the widgets.  Yet another one is to do that myself
>  (but I'm not too fond of that idea).  Another one is the included
>  patch, which only modifies the widgets-mesa/src/Makefile in order to
>  generate a libGLw.a library which has the same stuff as the "xfree86"
>  library (modulo the Motif 1/Motif 2 functions).  Please note the motif
>  library is still called libGLwM.a.
> 
>  Thank you in advance for your input,

I'd forget about widgets-mesa.  The one special thing it has is
better colormap/visual selection code for when you're running on
an 8-bit display.  It tries to avoid colormap flashing.  Few people
run 3D apps at 8bpp nowadays.

The widgets-sgi directory has the SGI-authored widgets and is
probably the better code to promote.

-Brian

Re: [Mesa3d-dev] Texture conversion in 3.4.x?

[Brian P. <br...@va...>]

Gareth Hughes wrote:
> 
> Brian,
> 
> I backed out my texture conversion work from my DRI branch to get the
> Radeon up and running with (what will become) 3.4.1.  Of course, I
> realized in about thirty seconds why I'd done all the work in the first
> place, as there are format pairs that the Radeon requires that currently
> aren't supported.  And, having already done the work to support them, I
> don't really want to hack a solution into the old code just to make it
> fit.
> 
> So, I would like to include this work into what will become Mesa 3.4.2,
> so that the Radeon driver can use the single-copy interface with 3.4
> (ie. before the 3.5 driver becomes standard).  I realize that this new
> code should not be included in 3.4.1 at this late stage, but do you have
> a problem with it going in after 3.4.1 is released?  I'm not sure what
> your policy is on this (this code still uses the GetTexImage function,
> not the new ExtractTexel code, if it counts).

I have no plans for a 3.4.2 release at this time.

I'd suggest adding the new Radeon texture formats to the 3.4.1
texutil.c code.  That shouldn't be a big job and would be a safe
modification, I'd think.  I'll probably release 3.4.1 in the next
24 hours.  If you don't get the new texel formats into 3.4.1 for
the release that's no big deal.  The mesa_3_4_branch will still
exist.

The ExtractTexel stuff is in 3.5 and will never be back ported
to 3.4.x.

-Brian

[Mesa3d-dev] Re: libGLw.a vs libMesaGLw.a vs libMesaGLwM.a?

[Marcelo E. M. <mma...@de...>]

>> "Marcelo E. Magallon" <mma...@de...> writes:

 >  Another one is the included patch

 I'm sorry.

[Mesa3d-dev] libGLw.a vs libMesaGLw.a vs libMesaGLwM.a?

[Marcelo E. M. <mma...@de...>]

Hi,

 I was updating the Debian package for Mesa and I want to make sure I'm
 not going to mess up things.  In Debian there are several Mesa packages
 available: the ones from the mesa source (the "regular" mesa, a glide2
 package, a ggi package, plus a development package) and the ones coming
 from the XFree86 sources (the "regular" mesa, xlibmesa3[1], a
 development package, xlibmesa-dev, and a OSMesa package).  The 3.2
 packages still have some libMesaGL -> libGL symlinks which I'm going to
 remove in the 3.4 package (or 3.4.1).  What I'm not sure what to do
 with is the libMesaGLw library.  The xlibmesa-dev package provides
 libGLw.a, which contains the following symbol definitions:

    GLwDrawingAreaMakeCurrent
    GLwDrawingAreaSwapBuffers
    glwDrawingAreaClassRec
    glwDrawingAreaWidgetClass
    glwMDrawingAreaClassRec
    glwM1DrawingAreaWidgetClass
    glwM2DrawingAreaWidgetClass
    GLwCreateM1DrawingArea
    GLwCreateM2DrawingArea
    glwMDrawingAreaClassRec

 which is slightly different from what's generated using the sources in
 widgets-mesa.

 The other difference is the name of the library itself.  mesa generates
 libMesaGLw and libMesaGLwM, depending if the Motif version of the
 widgets is enabled or not.  This library also provides the "mesa"
 functions (e.g., mesaDrawingAreaClassRec).

 My problem with all of this is that the the "xfree86" packages provide
 libGLw.a as part of the aforementioned xlibmesa-dev package, which
 means the mesag-dev[2] package has to provide this file in some
 (compatible) way.

 One possible solution for me is to just ask the XFree86 maintainer to
 split the widgets out of the xlibmesa packages and don't use the ones
 provided by the mesa source.  The other one is to ask you guys to use
 the SI source for the widgets.  Yet another one is to do that myself
 (but I'm not too fond of that idea).  Another one is the included
 patch, which only modifies the widgets-mesa/src/Makefile in order to
 generate a libGLw.a library which has the same stuff as the "xfree86"
 library (modulo the Motif 1/Motif 2 functions).  Please note the motif
 library is still called libGLwM.a.

 Thank you in advance for your input,


                                Marcelo

 [1] If you are asking yourself about this name, that makes two of us.
 [2] the "g" is a remanent of past times, when there was a mesa-dev
     package that provided a libc5 development environment.

[Mesa3d-dev] Texture conversion in 3.4.x?

[Gareth H. <ga...@va...>]

Brian,

I backed out my texture conversion work from my DRI branch to get the
Radeon up and running with (what will become) 3.4.1.  Of course, I
realized in about thirty seconds why I'd done all the work in the first
place, as there are format pairs that the Radeon requires that currently
aren't supported.  And, having already done the work to support them, I
don't really want to hack a solution into the old code just to make it
fit.

So, I would like to include this work into what will become Mesa 3.4.2,
so that the Radeon driver can use the single-copy interface with 3.4
(ie. before the 3.5 driver becomes standard).  I realize that this new
code should not be included in 3.4.1 at this late stage, but do you have
a problem with it going in after 3.4.1 is released?  I'm not sure what
your policy is on this (this code still uses the GetTexImage function,
not the new ExtractTexel code, if it counts).

-- Gareth

Re: [Mesa3d-dev] back to autoconf 2.13

[Keith W. <ke...@va...>]

"Sven M. Hallberg" wrote:
> 
> Greetings,
> 
> I have rearranged the configure.in to work with autoconf v2.13 again.
> Unfortunately it is now no longer possible to use configure to compile a Mesa
> with missing GLUT and/or demo source directories. However, one might consider
> making those seperate packages, thus giving them their own configure script...
> But that's another story.
> 
> Anyways, my first show at building died with cpp unable to find
> GL/include/glcore.h, included from glheader.h. I have not been able to find
> that file anywhere, however my old locate db indicated it used to reside
> in the Mesa src/ dir. Am I missing something or is this a bug?
> 
> Regards,
> Sven

You  probably need to do a 'cvs update -d' as it's in a new directory.

Keith

[Mesa3d-dev] sources.lst files

[Sven M. H. <pe...@gm...>]

Again,

I thought I'd drop a note about this, so nobody trips over it.

As there is a lot of flux in the list of source files especially in src/
it's hard to keep track of every file removed/renamed/moved/whatever. I've
assembled a script gen_srclists.sh in the top source dir that generates a file
source.lst in every directory which has a Makefile.am with exactly one SOURCES
directive and an "include sources.lst" line. It fills sources.lst with simply
a sorted list of all .c and .h file in the respective directory.

The script is just meant as a hack to quickly create _some_ list of files. If
that list is not 100% right it can easily be corrected. Further, renaming the
list file will of course lock the script out.


Regards,
Sven

PS: Maybe we could even modify the "manual" Makefiles to use these list files.
    That way the need for seperate maintainance of the traditional and the
    automake lists would disappear. Comments anyone?

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

[Mesa3d-dev] back to autoconf 2.13

[Sven M. H. <pe...@gm...>]

Greetings,

I have rearranged the configure.in to work with autoconf v2.13 again.
Unfortunately it is now no longer possible to use configure to compile a Mesa
with missing GLUT and/or demo source directories. However, one might consider
making those seperate packages, thus giving them their own configure script...
But that's another story.

Anyways, my first show at building died with cpp unable to find
GL/include/glcore.h, included from glheader.h. I have not been able to find
that file anywhere, however my old locate db indicated it used to reside
in the Mesa src/ dir. Am I missing something or is this a bug?


Regards,
Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

Re: [Mesa3d-dev] Mesa 3.4.1 heads-up

[Brian P. <br...@va...>]

Brian Paul wrote:
> 
> I'd like to release Mesa 3.4.1 within the next week.  It'll
> basically be just a bug-fix release.  Does anyone have any
> outstanding work that should be included?


I'm going to hold off on the 3.4.1 release for a few more days.
I'm waiting for feedback on a couple of outstanding bugs.

-Brian

[Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: mesa_3_4_branch)

[Brian P. <br...@va...>]

Jacob Jansen wrote:
> 
> CVSROOT:        /cvsroot/mesa3d
> Module name:    Mesa
> Repository:     Mesa/vms/
> Changes by:     joukj@usw-pr-cvs1.      01/02/09 00:25:18
> 
> Modified files:
>       Mesa/demos/:      Tag: mesa_3_4_branch
>         descrip.mms
>       Mesa/src/:        Tag: mesa_3_4_branch
>         descrip.mms
>       Mesa/src/X/:      Tag: mesa_3_4_branch
>         glxheader.h xfonts.c xfonts.h
>       Mesa/src-glu/:    Tag: mesa_3_4_branch
>         descrip.mms
>       Mesa/src-glut/:   Tag: mesa_3_4_branch
>         descrip.mms
>       Mesa/vms/:        Tag: mesa_3_4_branch
>         analyze_map.com xlib_share.opt
> Added files:
>       Mesa/include/GL/: Tag: mesa_3_4_branch
>         vms_x_fix.h
> 
>   Revision      Changes    Path
>   1.1.1.1.6.1   +158 -41   Mesa/demos/descrip.mms
>   1.13.4.1      +1 -1      Mesa/src/descrip.mms
>   1.1.4.1       +5 -1      Mesa/src/X/glxheader.h
>   1.6.4.4       +6 -1      Mesa/src/X/xfonts.c
>   1.1.4.1       +5 -1      Mesa/src/X/xfonts.h
>   1.4.4.1       +137 -21   Mesa/src-glu/descrip.mms
>   1.2.6.1       +139 -121  Mesa/src-glut/descrip.mms
>   1.2.6.1       +4 -1      Mesa/vms/analyze_map.com
>   1.1.6.1       +2 -0      Mesa/vms/xlib_share.opt
> 
> Log message:
>    Modified Files:
>     Tag: mesa_3_4_branch
>         Mesa/demos/descrip.mms Mesa/src/descrip.mms
>         Mesa/src/X/glxheader.h Mesa/src/X/xfonts.c Mesa/src/X/xfonts.h
>         Mesa/src-glu/descrip.mms Mesa/src-glut/descrip.mms
>         Mesa/vms/analyze_map.com Mesa/vms/xlib_share.opt
>    Added Files:
>     Tag: mesa_3_4_branch
>         Mesa/include/GL/vms_x_fix.h
> 
>    backported from version 3.5 some VMS compile issues


It looks like the vms_x_fix.h file is only included by files in
the Mesa/src/X/ directory.  Is vms_x_fix.h ever included by client
programs?  If not, vms_x_fix.h should be moved to Mesa/src/X/.
The headers in Mesa/include/GL are meant to be public headers
which may be included by client programs, not headers internal
to Mesa.

-Brian

Re: [Mesa3d-dev] Mesa 3.4.1 heads-up

[Scott M. <mcm...@ca...>]

Unfortunately it was one of those problems where I could
resize the window up to about 20 times before I hit the
right timing or combination that set off the error.

Having said that, however, I just resized the window
about 100 times in a row without failure.

Thanks,
scott

Brian Paul wrote:
> 
> Brian Paul wrote:
> >
> > Scott McMillan wrote:
> > >
> > > I just submitted a problem in _mesa_clear_depth_buffer() to
> > > the bug list, that I would like to see fixed.
> >
> > Scott, is your window manager set to do opaque resizes?  I.e.
> > does the window constantly resize as you move the mouse?
> > Or, does interactive resizing use a rubberband rectangle?
> 
> Nevermind.  I found the problem.  I'm sending you an updated
> Mesa-3.4/src/depth.c file for you to try.  Let me know if
> you still have trouble.
> 
> -Brian

-- 
Scott McMillan                        mailto:mcm...@ca...
Cambridge Research Associates         http://www.cambridge.com
1430 Spring Hill Road, Ste. 200       Voice: (703) 790-0505 x7235
McLean, VA 22102                      Fax:   (703) 790-0370

Re: [Mesa3d-dev] Mesa 3.4.1 heads-up

[Brian P. <br...@va...>]

Brian Paul wrote:
> 
> Scott McMillan wrote:
> >
> > I just submitted a problem in _mesa_clear_depth_buffer() to
> > the bug list, that I would like to see fixed.
> 
> Scott, is your window manager set to do opaque resizes?  I.e.
> does the window constantly resize as you move the mouse?
> Or, does interactive resizing use a rubberband rectangle?

Nevermind.  I found the problem.  I'm sending you an updated
Mesa-3.4/src/depth.c file for you to try.  Let me know if
you still have trouble.

-Brian

Re: [Mesa3d-dev] Mesa 3.4.1 heads-up

[Brian P. <br...@va...>]

Scott McMillan wrote:
> 
> I just submitted a problem in _mesa_clear_depth_buffer() to
> the bug list, that I would like to see fixed.

Scott, is your window manager set to do opaque resizes?  I.e.
does the window constantly resize as you move the mouse?
Or, does interactive resizing use a rubberband rectangle?

-Brian

Re: [Mesa3d-dev] Mesa 3.4.1 heads-up

[Brian P. <br...@va...>]

Scott McMillan wrote:
> 
> I just submitted a problem in _mesa_clear_depth_buffer() to
> the bug list, that I would like to see fixed.

I'll look into it.  Thanks.


> Also, the
> NURB surfaces seem to have a problem computing proper
> normals for a view of the points on the surface.  I just
> saw this one in my testBezierSurfaces program in SGL
> (sgl.sourceforge.net) about 15 minutes ago, and have not had
> time to characterize it better...but it is similar to a
> problem I reported before the release of 3.4, that I
> thought had been fixed (but perhaps not).  I won't have
> a chance to check out a CVS view in the next few days.

Likely a problem in Mesa's GLU library.  You might want to
use the SGI SI GLU library instead.  You can download it
from the Mesa website.  I plan to replace Mesa's GLU with
the SI GLU in the future.

-Brian

Re: [Mesa3d-dev] Mesa 3.4.1 heads-up

[Scott M. <mcm...@ca...>]

I just submitted a problem in _mesa_clear_depth_buffer() to
the bug list, that I would like to see fixed.  Also, the
NURB surfaces seem to have a problem computing proper
normals for a view of the points on the surface.  I just
saw this one in my testBezierSurfaces program in SGL
(sgl.sourceforge.net) about 15 minutes ago, and have not had
time to characterize it better...but it is similar to a
problem I reported before the release of 3.4, that I 
thought had been fixed (but perhaps not).  I won't have
a chance to check out a CVS view in the next few days.

Brian Paul wrote:
> 
> I'd like to release Mesa 3.4.1 within the next week.  It'll
> basically be just a bug-fix release.  Does anyone have any
> outstanding work that should be included?
> 
> -Brian

-- 
Scott McMillan                        mailto:mcm...@ca...
Cambridge Research Associates         http://www.cambridge.com
1430 Spring Hill Road, Ste. 200       Voice: (703) 790-0505 x7235
McLean, VA 22102                      Fax:   (703) 790-0370

Re: [Mesa3d-dev] Mesa 3.4.1 heads-up

[Gareth H. <ga...@va...>]

Brian Paul wrote:
> 
> I'd like to release Mesa 3.4.1 within the next week.  It'll
> basically be just a bug-fix release.  Does anyone have any
> outstanding work that should be included?

I think the basic texture conversion work is done.  There needs to be
some integration into 3.5, but the initial layered framework is
complete.  I'll make sure the tdfx and Radeon drivers work fine with it
before I commit it to Mesa CVS.

How does this sound?

-- Gareth

[Mesa3d-dev] Mesa 3.4.1 heads-up

[Brian P. <br...@va...>]

I'd like to release Mesa 3.4.1 within the next week.  It'll
basically be just a bug-fix release.  Does anyone have any
outstanding work that should be included?

-Brian

Re: [Mesa3d-dev] problem in Mesa-CVS version

[Brian P. <br...@va...>]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> For some time I'm now struggleling with the stairs demo of xlockmore
> (see ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/). It occasionally crashes
> with the distribution of Mesa in CVS (main branche) and the bouncing balls
> shows a light band.
> 
> I just checked with Mesa3.4 and could not reproduce these problems. So the
> MesaCVS seems to be suspect for this program.
> 
> Note that all the other OpenGL demo's of xlockmore seem to work fine.
> 
> I'm running this on my OpenVMS 7.2-1 Box.

I can't reproduce the crash on my system.

I think there's a bug in the stairs code.  Texturing is always enabled
but the ball is drawn without specifying any texture coordinates.

Technically, the ball should be drawn using whatever texture coordinate
was last specified.  This would result in the same texel being used
over the whole object.  It appears this his happening with Mesa 3.4
but not with Mesa 3.5.  So, there's probably a bug in Mesa 3.5 too.

Keith, any ideas?

-Brian

[Mesa3d-dev] problem in Mesa-CVS version

[<jo...@hr...>]

Hi all,

For some time I'm now struggleling with the stairs demo of xlockmore
(see ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/). It occasionally crashes
with the distribution of Mesa in CVS (main branche) and the bouncing balls
shows a light band.

I just checked with Mesa3.4 and could not reproduce these problems. So the
MesaCVS seems to be suspect for this program.

Note that all the other OpenGL demo's of xlockmore seem to work fine.

I'm running this on my OpenVMS 7.2-1 Box.

                 Jouk


Bush : All votes are equal but some votes are more equal than others.

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<