| Summary: | [llvmpipe] Line antialiasing looks different when GL_LINE_STIPPLE is enabled with pattern 0xffff | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Florian Link <florianlink> |
| Component: | Other | Assignee: | 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 |
||
Created attachment 121811 [details]
GL_LINE_STIPPLE disabled
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... (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. 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.
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?