[Bf-committers] OpenGL Profiles Project?
mburrack at yahoo.com
Thu Oct 7 10:46:05 CEST 2010
> That is exactly what is going on with swap method, people
> can manually
> select if they see fit. Read that again, it says "can", it
> does not
> say "must" or "have to". Out of the box they get a best
> guess that
> should work in many cases, only in the special ones it
> becomes "must"
> if they want good behaviour. When such new case is found
> and reported,
> the code is changed to cover it and the "must" goes away.
> Sincerily, it pretty much sounds like you both are saying
> the same but
> not realizing it is. Only real diff is current method has
> GUI for
> override and C code for control, and you propose all in
Almost, yes, but there's a few differences I think are key.
1) The exceptions config file. The manual control in your case gives the user an optional override to the auto detection, but if it's required for card X, then *every* user with card X will have to go in and set that override, unless we change the code to compensate. My way, Blender auto-saves a config file out based on the user's changes, which all we have to do is test before integrating it in (no code changes required).
At least two people at this point (I think; I'll have to go back and read to be sure about the count) have objected to the "exceptions list" because, essentially, the user should just manage it themselves. I don't disagree with the manual control--I disagree with it being relied on per user rather than as a last resort.
2) I proposed Python because it looks like, starting with 2.5 at least, that's the "preferred" method, and the GUI gets built on top of it. Not saying there shouldn't be a GUI, just that building the GUI should be a separate step from the profile/tweaking/exceptions code itself.
Otherwise, at least with you and I, it seems like are mostly on the same page...
More information about the Bf-committers