On Tue, Dec 03, 2002 at 04:15:40PM -0800, Allen Akin wrote: > On Tue, Dec 03, 2002 at 03:29:32PM -0800, Ian Romanick wrote: > | > | ... On Windows, I can go into the OpenGL tuning app for my driver and > | click 'force anisotropic filtering.' Since this extension was created AFTER > | Quake, there's NO WAY to enable it from Quake. In Linux I get tough > | cookies, but on "that other" operating system I get anisotropic filtered > | goodness. Which do YOU think is the better user experience? > > 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."
And if the performance hit is too much, I have the CHOICE to turn it back off. Pretty neat! 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...even if that dictation is only through lack of clairvoyance to know what future hardware could do. :) > | The problem is that for some knobs (like ones created after the apps), the > | only place where they can possibly be turned is at the system level. > > You picked a control that can be turned on without too much damage to a > game. However, I'd bet it would cause the conformance tests to fail, > and might cause silently incorrect results for film/video editing > software that Linux-based effects houses use. So globally enabling even > such a simple control isn't hazard-free. Time out. I don't think that anyone has suggested that any settings be global, system wide. Every "tweak" utility that I have seen in the last 5 years allows the creation of application specific profiles. I have to agree that doing so in the DRI would be a bad, BAD idea. If forcing some particular option gives undesirable results in one app, fine. Don't enable it in that app's profile. If enabling a particular option is the only way to get acceptable performance or work around a bug (potentially in the driver, see the EXT_specular_color thread from last week), fine. Set it only for the apps that need it. Don't want to worry about any of it, fine. Leave all the settings at the defaults. 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. That giving the user the ability to make his/her own judgements about the quality / conformance / performance trade offs (that app based settings might not be able to cover) could be seen as a bad thing for the user completely baffles me. The fact that every production quality OpenGL platform, except Linux & *BSD, from Irix to Windows to Mac OS provides this capability sets a pretty strong precedent. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html ------------------------------------------------------- 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
