[Bf-committers] New glLineWidth Policy
eiseljulian at gmail.com
Thu Feb 18 19:53:19 CET 2016
We talked about this in IRC before, but I'd like to get a final
conclusion on this topic and give other devs the chance to raise their
In a recent commit  we changed our policy for glLineWidth calls.
Previously, convention was to always reset to default (1.0) after
drawing with non-default width. New convention is to always ensure
line width is set to correct value before drawing lines (so there
basically is no default state anymore).
The changed policy caused quite a few regressions, which we can fix of
course - issue is finding them. The main reasons I'm not sure about
this however, are in the following:
Although it might look like state changes were reduced, I'm afraid
we'll end up with more state changes than before, since we do much
more line draw calls than glLineWidth calls to change to non-default
(>400 vs <100). Campbell made the point that we shouldn't need to be
too paranoid, adding glLineWidth all over, but I guess a fair amount
of paranoia would actually be needed since it's often hard to predict
all possible previous line-width states. And not to forget, when
adding code with changed line-width you also had to check possible
following draw calls.
Another point Campbell made, is that old policy would be hard to
follow for nested draw calls. Although I agree it's a valid point, we
managed to do it all the time, so it's obviously doable (Sergey added
we should avoid nested draw calls anyway).
So IMHO, this is too much hassle, and output isn't guaranteed to be worth it...
All that said, I could live with the new convention of course, but
let's review it first again :)
- Julian -
More information about the Bf-committers