> > Specifically, you're putting the burden on the user to
> determine
> > whether their graphics card supports GL_POINTS
> correctly or not. End
> > users don't want to bother with that; they just want
> to get
> > modeling!
>
> Some cards/drivers claim X, then give you "X by software"
> (looks
> correct, but too slow) or "X done to the basic level
> required by spec"
> (compliant but slow and/or not looking as expected by coder
> that
> wanted the extras). In both cases, being able to manually
> pick Y is a
> lot better than being stuck with X,
Actually, in both cases, *using* Y is a lot better than being stuck with X.
Manually choosing Y has nothing to do with it, because in both cases, X will be
unequivocally less desirable. Do you want the option to be able to Y instead of
X in those cases? Absolutely. Should the user have to intervene to pick Y
instead of X? No, not if at all possible.
> Or the other option, the driver
> gets fixed
> or improved and X becomes fast and implements the full
> spec, so now Y
> is the wrong thing.
At which point, you update the exceptions list from:
vendor.device.*:
do Y instead of X
to:
vendor.device.version < foobar:
do Y instead of X
This is expected, and inevitable as drivers are updated. *Something* will have
to be changed as the drivers are updated; in my case, it's just a configuration
file instead of the code, and all you need is one updated exception config file
to push out to users, instead of having every single user go back into the
preferences and unselect the "do Y instead of X" option.
In fact, in my proposal, instead of *every* user doing that, only *one* has to
do that and submit the updated exceptions file as a patch. All future users
benefit automatically.
> So having a manual option means reducing the pains but also
> the delays
> from updating to guess code. IE, happier users, and even
> better,
> people being able to test what workarrounds must be added
> or if the
> old workarround can be disabled now or still needed.
>
> ...
>
> So in the end there should be a manual override system on
> top of code
> that tries to do a first guess. Just like the swap method
> selection.
My suggestion for the Python API for the exceptions list satisfies that. Yes,
you need the "manual control" one way or another; the fundamental difference
I'm proposing is that, instead of having *every* user needing to modify those
exceptions manually, that we save them back out and store them in such a way
that they can be submitted as a patch so that, ideally, only one user (or at
least a small subset) need to actually bother with the manual control. Everyone
else just downloads an update and benefits automatically.
--mcn
_______________________________________________
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
