Bug 94193

Summary: [llvmpipe] Line antialiasing looks different when GL_LINE_STIPPLE is enabled with pattern 0xffff
Product: Mesa Reporter: Florian Link <florianlink>
Component: OtherAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact: mesa-dev
Severity: normal    
Priority: medium    
Version: 10.6   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: the thicker line
GL_LINE_STIPPLE disabled

Description Florian Link 2016-02-17 15:45:49 UTC
Created attachment 121810 [details]
the thicker line

When rendering lines with

glEnable(GL_LINE_SMOOTH);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glLineWidth(3)
glEnable(GL_LINE_STIPPLE);
glLineStipple(1, 0xffff);

// draw line strip...

the lines look thicker and have uglier antialiasing as if rendered with:

glEnable(GL_LINE_SMOOTH);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glLineWidth(3)
glDisable(GL_LINE_STIPPLE);

// draw line strip

When doing the same on NVidia or ATI OpenGL drivers, the lines look the
same.

Maybe it would make sense to detect the 0xffff pattern in MESA
and to not enable stippling when that pattern is set?
Comment 1 Florian Link 2016-02-17 15:46:36 UTC
Created attachment 121811 [details]
GL_LINE_STIPPLE disabled
Comment 2 Roland Scheidegger 2016-02-17 19:12:37 UTC
So if I understand this right, there's really two issues here:
1) smooth lines don't quite work when line stippling is enabled
2) we don't optimize fake-enabled line stippling away

As for 2), this is something the state tracker could do. I don't know if that's worth it? I think we generally only optimize for stupid gl state settings like this if there's actually apps out there which really do these stupid things. So, are there such real apps?

As for 1), I can't quite see why it wouldn't look the same. The draw stipple stage should create a single new line in the end which should be identical to the original one, and this should then still enter the aaline stage as it would without line stippling. Clearly looks like a bug to me...
Comment 3 Brian Paul 2016-02-17 20:59:47 UTC
(In reply to Roland Scheidegger from comment #2)
> So if I understand this right, there's really two issues here:
> 1) smooth lines don't quite work when line stippling is enabled
> 2) we don't optimize fake-enabled line stippling away
> 
> As for 2), this is something the state tracker could do. I don't know if
> that's worth it?

I actually recently looked at that myself but disabling line stipple if the pattern is 0xffff would potentially violate a GL invariance rule.  It would depend on the driver/GPU.

The deal is GL allows stippled lines with pattern = 0xffff to hit different pixels than the same line drawn with stippling disabled.  But with pattern = 0xffff you should be guaranteed to hit the same pixels as two complementary patterns such as 0xff00 and 0x00ff.  

In fact, GL allows quite a few "no-op" states (such as blend GL_ONE/GL_ZERO, glAlphaFunc(GL_ALWAYS), etc) which seem useless but are included for invariance purposes.

I don't know if anyone would depend on this particular line stipple behaviour in practice though.


> I think we generally only optimize for stupid gl state
> settings like this if there's actually apps out there which really do these
> stupid things. So, are there such real apps?

Oh, yes! :)  A CAD app I was working on a few months ago draws many lines with stippling enabled with pattern 0xffff.  But I think it was just sloppiness and not invariance-driven.
Comment 4 Roland Scheidegger 2016-03-15 19:01:01 UTC
Fixed by 12a4f0bed6ff03031587e1eb6d69f18b131f5655.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.