On Tue, Dec 03, 2002 at 04:35:49PM -0800, Linus Torvalds wrote: | | > Depends. How much performance will I lose on my machine when I force | > anisotropic filtering on? Just because you can turn the feature on | > doesn't mean you automatically get a "better user experience." | | But that's the POINT!
Nope. I haven't been arguing against the existence of controls for the user; just about where they reside in the system and what mechanisms are used to implement them. Ian suggested that forcing anisotropic filtering will give you a better user experience. I just pointed out that it ain't necessarily so. Therefore you can't use that as a compelling argument to force the app to do things it wasn't designed to do. | Which is why you'd want per-program (or per-process) knobs to tune the | behaviour. Yep. | Something like environment variables, in short. Not global config files. | Not static choices by the libraries. Environment variables typically persist as long as the shell in which they're set. If the variables provide controls at the wrong level (for example, they control the behavior of the library rather than the app), then you run serious risk of them getting stale. Users set variables (in their .bashrc or by explicit commands), run an app, and a while later run another app without realizing that the environment variable settings are no longer appropriate. That's a bad source of difficult-to-reproduce bug reports...and it could only get worse as more apps start to use OpenGL in non-3D ways that make the OpenGL-ness less obvious to the user. Wrappers or other techniques can work around that, but as I said in a previous message, the main issue isn't the choice of environment variables, config files, or whatever as a control mechanism. The main issue is keeping controls at the application (or process) level, not allowing them to spill over into the library or system where they can muck up unrelated code. Only the app is at the right abstraction level to have the information needed to make meaningful user controls. Q3A is an example of a good approach; environment variables that override default library behavior for texturing are an example of a bad approach. 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
