[Bf-committers] OpenGL Profiles Project?

GSR gsr.b3d at infernal-iceberg.com
Thu Oct 7 04:03:19 CEST 2010


Hi,
mburrack at yahoo.com (2010-10-06 at 0815.35 -0700):
> The irony is that, at least IMHO, the specific example you gave
> actually supported my idea of *not* having user intervention.
>
> 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, even if down the road an exception
will be added so Blender knows it has to pick Y, because all that time
you have been "enjoying" X. 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.

One example inside Blender is swap mode (triple buffer, overlap,
etc). It sounded like a great thing, but once people started testing
with other cards than the developer's one, problems appeared. Auto
select was added to tune "out of the box" behaviour, but manual
override was kept.

As another example of thrusting the drivers to use advertised options,
that are slower and worse looking than the old fallbacks, you can
check the latest rants arround KDE. Probably if they had an manual
override from start they could had collect user reports to make better
guesses, whilst people would be getting good performance until a new
release that integrates the changes is done.

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.

[...]
> The code could also store what exception set from the exceptions
> file matched the current profile. If/when the Python API is called
> to change a value in the profile, we automatically write out the
> updated exceptions to the exception file. That way, developers (and
> hard-core users) have a way of tweaking the exceptions file without
> manually editing it, and plus they can check the tweaks in
> real-time. If someone tweaks their particular setup to a "better"
> profile, all they have to do is submit the updated exceptions file
> as a patch, and we merge in the new set of exceptions (after any
> appropriate testing, of course).

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.

GSR
 


More information about the Bf-committers mailing list