On Wed, 26 Jan 2000, mitch wrote:
I think that the good parts of Opengl should be merged to the bad parts
of mesa. Also, is there anyway to squeeze some more speed out of mesa?
It seems that mesa is a good 8 to 10 FPS slower than Opengl with most
apps and is much slower for low resolutions.
On Thu, 27 Jan 2000, Jacob (=Jouk) Jansen wrote:
[EMAIL PROTECTED] wrote on 26-JAN-2000 18:40:01.60
Stephen J Baker wrote:
On Wed, 26 Jan 2000, Adam D. Moss wrote:
Stephen J Baker wrote:
I was wondering about whether we should consider
dropping GLUT from the next major Mesa
So, what does this:
http://www.quicken.com/investments/news/story/pr/?story=/news/stories/pr/2126/sfw052.htmsymbol=SGI
...mean for the future of Mesa?
Steve Baker(817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-2466 (Fax)
Work: [EMAIL PROTECTED]
On Wed, 26 Jan 2000, Adam D. Moss wrote:
Stephen J Baker wrote:
I was wondering about whether we should consider
dropping GLUT from the next major Mesa distribution
(3.4 I guess) and replacing it with 'freeglut'
FWIW I think that this is a good idea, though I
can't say whether
On Wed, 26 Jan 2000, Brad Grantham wrote:
From [EMAIL PROTECTED] Wed Jan 26 11:24:14 2000
So, what does this:
http://www.quicken.com/investments/news/story/pr/?story=/news/stories/pr/2126/sfw052.htmsymbol=SGI
...mean for the future of Mesa?
I imagine (but do not know)
On Wed, 26 Jan 2000, Brian Paul wrote:
I didn't even know that freeglut existing until this morning.
Yep. It hasn't been well advertized - and it's very new.
What exactly are the terms of Mark's copyright on GLUT?
It's in the file 'NOTICE' in the top of the GLUT distro.
It says:
On Wed, 26 Jan 2000, JONATHAN DINERSTEIN wrote:
I think that open source OpenGL will eventually replace Mesa for the simple
fact that vendors will trust SGI's OpenGL over Mesa. I'm not saying that Mesa
is a poor library, but that SGI's OpenGL has the SGI name attached.
For the best
On Wed, 26 Jan 2000, JONATHAN DINERSTEIN wrote:
I don't like the idea of giving Mesa away for SGI to act as gatekeeper.
I think we have to think more in terms of pulling stuff out of SI and
into Mesa - if the license can be straightened out in *that* direction.
I can agree with your
On Wed, 1 Dec 1999, JONATHAN DINERSTEIN wrote:
As an example of the kind of rendering errors I want to get rid of,
check out:
http://www.npl.com/~jon/
It is a jpeg so some amount of loss has happened, but you can still easily see
the problem. All I did was have GLUT draw
On Fri, 12 Nov 1999, Heriberto Delgado wrote:
My name is Heriberto Delgado. I'm new at this list, and pretend to
participate frequently on it. My current interest with Mesa is to
begin developing an -like API for the Palm (Pilot, as it was known some
time ago). By now, I have some working
On Thu, 11 Nov 1999, Kendall Bennett wrote:
Hi Brian,
1. #define MESA_MINOR_VERSION 1
Shouldn't this be "3" instead of "1"? (GL\gl.h)
The MESA_MAJOR_VERSION and MESA_MINOR_VERSION defines in gl.h are
going away. I'm trying to make Mesa's headers more compatible with
OpenGL's.
On Thu, 11 Nov 1999, Kendall Bennett wrote:
Forwarded message:
From: Self KendallB
To: Brian Paul [EMAIL PROTECTED]
Subject: Re: [Mesa-dev] branching plans
Date: Wed, 10 Nov 1999 19:41:16 -0800
Hi Brian,
I plan on creating the 3.2 development branch today.
The branch tag will
On Sun, 7 Nov 1999, Jean-Francois Panisset wrote:
I imagine that there is a good reason for using enums instead of
#defines in the the Mesa gl.h and glu.h?
The other reason is that we'll want to be compliant with the
Linux OpenGL Base stuff - and for that it will be necessary to
use a
On Wed, 13 Oct 1999, Brian Paul wrote:
I've renamed the memory macros I created a few days ago. I removed
the GL_ prefix on each one in order to prevent future name-space
collisions with future GL enums/tokens.
The new macros are
MALLOC
CALLOC
MALLOC_STRUCT
CALLOC_STRUCT
FREE
It
On Wed, 15 Sep 1999, Brian Paul wrote:
I think we all agree that the library name should be
"libGL.so.1.2.something"
Josh's suggestion for something=030100 is good, even though I doubt
there'd be more than 9 patch levels to a given release.
If we don't encode the Mesa version in the
On Sat, 11 Sep 1999, Brian Paul wrote:
[cross-posting]
I've implemented this extension in Mesa 3.1 and checked it into
the CVS repository. I also implemented GLU_EXT_get_proc_address
and GLX_EXT_get_proc_address. Only the core extension has been
documented in the Mesa/docs/ directory at
On Fri, 10 Sep 1999, Keith Whitwell wrote:
I hadn't even considered fat lines (or stipples). I was just thinking about how
to define the two triangles which define the line - for points it's easy as the
offsets will be axis-aligned, but for lines I'm not sure you can get away with
just
On Tue, 7 Sep 1999, Brian Paul wrote:
Here's another issue. There's an effort underway to standardize
the OpenGL environment on Linux. One aspect of that is version
numbering for the libGL.so file (used to be libMesaGL.so).
I propose this lib name for the 3.1 release: libGL.so.1.2.310
On Tue, 7 Sep 1999, Brian Paul wrote:
I'd like to make a 3.1 beta 3 release by the end of next week.
Fellow developers, any concerns?
Is anyone going to put in the glGetFuncAddressEXT stuff before
then so we are essentially compliant with the new Linux OpenGL
Base spec?
Steve Baker
On Wed, 8 Sep 1999, Jon Taylor wrote:
Here's another issue. There's an effort underway to standardize
the OpenGL environment on Linux.
...Which explicitly states that this "standardization effort" is
predicated on the existence and use of X/GLX, and hence is not relevant
for
(Arguments with Allen are *so* informative...and also hard to win!)
On Wed, 1 Sep 1999 [EMAIL PROTECTED] wrote:
| You'd need to figure out which odd corner-cases could arise
| and how you want to handle them. What if you use a texture
| while you're rendering to
On Wed, 18 Aug 1999, Brian Paul wrote:
I have a feeling, however, that we'll have to rebuild the src/
CVS files from scratch. I've seen several badly corrupted files.
Whoever had a recent snapshot from before the crash should volunteer
to upload all their files.
What was that quote from
On Tue, 3 Aug 1999, Keith Whitwell wrote:
I've checked in some code which I think fixes the 2 outstanding bugs reported by
Miklos.
It's been a little hard to keep track of what's happening with bugs, so at the
risk of starting a deluge I'm going to ask everyone who's (1) got a bug in
On Thu, 10 Jun 1999, Thomas Tanner wrote:
2. There is the public interface which connects OpenGL/Mesa to the
OS / window system. This interface, by definition, is unique to
each system. These are the GLX, WGL, OS/Mesa, SVGA, Glide, etc
interfaces.
Yes. That's what I want
On Tue, 8 Jun 1999, Brian Paul wrote:
The real question is whether Brian wants the next release version to
include the new code or not.
I don't have a date in mind for the next beta release.
I'd like to keep the mainline code pretty much stable. After Keith
has tested and debugged
On Tue, 8 Jun 1999, Holger Waechtler wrote:
Who says, that our super driver is not able to load it's subdrivers
dynamically ??
(could you explain, how dlopen() is used ?? - works it on non-Unix
platforms (MacOS, Dos, Windows) ?? -- if not, we could put some #ifdef's
around it and link at
On Tue, 8 Jun 1999, Holger Waechtler wrote:
On Mon, 7 Jun 1999 [EMAIL PROTECTED] wrote:
On Mon, 7 Jun 1999 14:04:49 -0700, Keith Whitwell wrote:
Can't we have a prebuilt ./configure in the repository?
This is generally considered to be a Bad Idea, since configure is
On Tue, 25 May 1999, Thomas Tanner wrote:
For the long term though I think autoconf probably is the right way
to go.
So many OpenSource packages use it now, I think Mesa should switch to
it soon or risk looking very out of date.
A few concerns:
1. As you point out, there's probably
On Wed, 26 May 1999, charlie wallace wrote:
why not just standardize makes across as many platforms as
possible, ie dmake . which is available on almost every platform
mesa is.
projects files are useful too, makefiles can be incredibly esoteric,
each to their own. I dont see why the mesa
On Mon, 24 May 1999, Brian Paul wrote:
what do you think about using GNU autoconf/automake/libtool for Mesa?
1. As you point out, there's probably a few non-Unix systems that
don't have autoconf but work with the existing Makefiles. Traditional
Makefiles will probably still be needed.
On Tue, 18 May 1999, Kendall Bennett wrote:
Anyway, the more I thought about this and the more we discussed it
amongst ourselves here at SciTech, the more we realised that the
problem is that there is currently no mechanism for any commercial
organisation to put funding behind Mesa.
I
On Thu, 6 May 1999, Brian Paul wrote:
This extension is still in Mesa. It's regarded as obsolete in favor
of GL_ARB_multitexture. I think the only app that really uses this
is Quake2.
Keith W. had asked about removing it since it's both obsolete and it
introduced some ugliness into the
On Sat, 3 Apr 1999, Brian Paul wrote:
I'm unable to
use gdb because when the crash occurs the X server is grabbed by
Quake so mouse keyboard are dead. If I don't use gdb the
segfault terminates Quake and X server is unlocked. I've been
using asserts and printf's to track it this far.
On Wed, 31 Mar 1999, Brian Paul wrote:
Just got a note from Zoid at Id. He's working on Quake3 with Mesa
for Linux. Evidently there's a big performance problem when using
the glPolygonOffset feature. He said Mesa 2.6 works fine but 3.0
is really slow.
Of course, it doesn't work at all
On Wed, 24 Mar 1999, Brian Paul wrote:
Keith W,
I was browsing the latest code to see where assembly language
optimizations will hook into the transformation code. It wasn't
obvious to me where this would happen.
Someone from Intel wrote me today that they've been testing PIII
On Mon, 1 Mar 1999, charlie wallace wrote:
one comment to add
Lint!!!
Most modern compilers produce better warnings than lint anyway...
presuming you use ANSI-stlye function prototypes and don't switch
to KR mode.
Steve Baker(817)619-2657 (Vox/Vox-Mail)
Raytheon Systems
On Wed, 3 Nov 1999, Brian Paul wrote:
Jean-Francois Panisset wrote:
[EMAIL PROTECTED]Brian Paul writes
For Mesa 3.3 (the new development) I'll extend the new imaging
code (in image.[ch]) into glDrawPixels, glCopyPixels and
glColorTable. Those functions might not get much faster
37 matches
Mail list logo
