Bug 94193 - [llvmpipe] Line antialiasing looks different when GL_LINE_STIPPLE is enabled with pattern 0xffff
Summary: [llvmpipe] Line antialiasing looks different when GL_LINE_STIPPLE is enabled ...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: 10.6
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-17 15:45 UTC by Florian Link
Modified: 2016-03-15 19:01 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
the thicker line (2.16 KB, image/png)
2016-02-17 15:45 UTC, Florian Link 		Details
GL_LINE_STIPPLE disabled (2.97 KB, image/png)
2016-02-17 15:46 UTC, Florian Link 		Details
View All

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.