On Tue, Dec 03, 2002 at 05:02:36PM -0800, Ian Romanick wrote:
|
| ...It's the year 2002 (almost 2003) and I can actually
| choose how to operate my computer instead of having somebody else dictate it
| to me...
Let me get this straight. The lack of ability to add new features to a
program without using its source code is "having somebody else dictate"
to you? :-)
I think the few cases in OpenGL apps where you could add functionality
or make bug fixes without source are wonderful serendipitous events.
But we lack perspective if we weight those cases too heavily. Far
better to concentrate on opening the source or providing help so that
closed-source apps do the right thing.
| ... I don't think that anyone has suggested that any settings be
| global, system wide. ...
Actually, some have. But even environment variables that silently apply
to all the apps run from the same shell are enough to cause problems.
| Consider this example. Say that there is some major, closed-source app in
| common use. Say that app has a subtle bug in it that causes it to crash
| with one driver, but it just happens to work with several other drivers. It
| is fairly common practice to work around such a bug in the driver. However,
| having such a work around may cause performance problems for a large number
| of other apps. It would be nice to be able to use the work-around *only*
| for the app that needs it. Either env vars or a config file (w/application
| specific profiles) could solve this problem. I don't think this is an at
| all outlandish or unbelievable example.
No, and as I've said several times before, I don't have a major problem
with it as long as the "knob" that controls the workaround is
application-specific. For example, if the workaround is for Q3A and
we're using environment variables, then the variable that controls it
should be named "GL_Q3A_SECONDARY_COLOR_WORKAROUND", or whatever. That
way there's no contamination of the environment for other apps when the
workaround is enabled for Q3A.
The approach I want to avoid is defining a bunch of general low-level
switches ("What's the default texel size?" "Should the multitexturing
extension be exposed?" "Is it OK for polygon rendering to be
non-conformant?" "Should hints default to NICEST or FASTEST?" and so
on, and so on, and so on. There would be hundreds.). This is not the
way to provide effective controls to the end user, it's not the way to
keep application behavior consistent from run to run on the same system,
and it doesn't even help make the driver developers' lives easier.
What the overwhelming majority of end users want to see is some
high-level control, like a slider that runs from "fastest" to "highest
quality." Such a thing can only be implemented properly by the apps,
because that's the only place in the system where there's enough
information to make intelligent tradeoffs.
For example, a user might try to force texels to be 16bpp in order to
speed up a game, but that'll be worse than useless if the game happens
to be geometry-bound rather than rasterization-bound. Only the game
itself knows enough to use coarser geometry to reduce the geometry
processing load and get a reasonable gain in speed.
That's where the big win is; at the application level, not in
library-level tweaks that make minor changes to driver behavior.
Anything we can do to make app-level preferences easier for app
developers to use is a good investment. The library-level stuff is a
lot less effective use of our limited time, and can lead to spurious
bugs.
Allen
-------------------------------------------------------
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
