[Bf-committers] New glLineWidth Policy

[Mike Erwin]

Hey Julian, thanks for bringing this up for discussion. The intentions of
that recent change were twofold, and you summed up the difference between
the new and old policy perfectly.

First intention was to reduce GL state changes -- which you say might not
be reduced. And more importantly to make each bit of line-drawing code
responsible for its own line width. To me it's way more paranoid for each
site to reset it back to 1.0 just in case some other unrelated draw call
forgets to set its own line width. Specifying state at the draw call site
is also more Vulkan-friendly, whenever we get to that.

I did a similar change set with point size a week or two before and it
seemed to work really well. Lines are drawn in many more places (and more
ways) so some things were not caught and updated to the new policy.

So yes, let's review whether or not the new policy is a good one. Naturally
I'm on Team Yes!

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Thu, Feb 18, 2016 at 1:53 PM, Julian Eisel <eiseljulian at gmail.com> wrote:

> Hey there,
>
> 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
> voice.
>
> In a recent commit [1] 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 :)
>
> [1] https://developer.blender.org/rBSe25ba162c0b
>
> Cheers,
> - Julian -
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>