Ian Romanick wrote:
On Tue, Dec 03, 2002 at 07:31:11AM -0700, Brian Paul wrote:
Felix Kühling wrote:
On Mon, 2 Dec 2002 18:43:25 -0800
Allen Akin <[EMAIL PROTECTED]> wrote:
On Mon, Dec 02, 2002 at 02:00:49PM +0100, Felix Kühling wrote:
| .... So if we agree on this, I would make this
| controlled by an environment variable. ...
The intent of the spec is that drivers should support whichever texture
internal formats they wish to support, and apps should choose between
them (or use the default only if they truly don't care). Environment
variables aren't very portable, and work around the intent of the spec.
Is there some compelling reason to use them, rather than just having the
driver do what was intended?
The intent of the environment variable is to allow users to tune the
operation of the driver to meet their needs.
> The environment
variable I'm going to add would enable the user to override the bpp
dependent default.
I'm with Allen in preferring that we don't add yet another environment
variable - especially for something which other OpenGL drivers haven't
needed.
I'm not sure that statement is accurate. On SGI, AIX, and Windows there are
various tools to tune the operation of the OpenGL driver. On Linux we don't
have any of that. Instead we've been using an ad-hoc collection of
environment variables to control debug output, HW TCL operation, page
flipping, refresh synchronization, and a ton of other stuff.
Perhaps it's time we thought about doing something better?
Sure, I'd rather see a coherent configuration system than another ad-hoc
environment variable (though env vars could be a part of that system).
As Keith pointed out, Chromium has a fairly neat solution to this problem.
-Brian
-------------------------------------------------------
This SF.net email is sponsored by: Microsoft Visual Studio.NET
comprehensive development tool, built to increase your
productivity. Try a free online hosted session at:
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
