Bug 99849

(In reply to Max Staudt from comment #0)
> This is a continuation of fdo#99708.
> 
> Basically, since X server commit d18f5801, dashed lines with zero width are
> accelerated through GLAMOR, and thus through OpenGL.
> 
> When using Mesa's software renderer, this is drawn as one continuous line.

Which software renderer?  swrast, softpipe, llvmpipe, swr?  I just did a quick test of softpipe and llvmpipe and stippled lines look OK here.

Which version of Mesa are you using?

(In reply to Brian Paul from comment #1)
> Which software renderer?  swrast, softpipe, llvmpipe, swr?  I just did a
> quick test of softpipe and llvmpipe and stippled lines look OK here.
> 
> Which version of Mesa are you using?

I am running stock components included in openSUSE Leap 42.2:
  Xephyr 1.18.3
  Mesa 11.2.2

From glxinfo when run in Xephyr:
  OpenGL vendor string: VMware, Inc.
  OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.8, 256 bits)
  OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.2
  OpenGL core profile shading language version string: 3.30


To reproduce this, start Xephyr like this:
  Xephyr -glamor :99

Then, run the program like this:
  DISPLAY=:99 ./x11dash

When you omit the -glamor parameter to Xephyr, or run on a system that does not use GLAMOR (such as with stock xf86-video-intel DDX), X will use its internal fallback software renderer for 2D drawing commands. It's important to involve the GLAMOR subsystem to reproduce this bug.

I've also reproduced this on the most recent openSUSE Tumbleweed snapshot, which includes Mesa 17.0.0 and Xorg 1.19.1.

Looks like this isn't using line stippling or anything like that, but just drawing a line with a texture attached, with a shader which discards pixel based on the texture value (I think using a A8 texture, I hope that works, since the fs is using the .w value - I have no idea there how pixmaps get converted into textures).
discard obviously is something that is known to work usually, as is ordinary line drawing (it's using GL_LINE_STRIP).
I'm not familiar enough with glamor to easily debug this though...

Xephyr -glamor is basically an OpenGL application like any other. E.g. you can create an apitrace reproducing the problem, if that helps.

FWIW I've actually captured a replay and when playing back on a nvidia blob, it doesn't show a dashed line neither (just solid).

I'm inclined to believe this is a glamor bug. The shader does
       float pattern = texture2D(dash, vec2(dash_offset, 0.5)).w;
       if (pattern == 0.0)
               discard;

But the texture bound at that time is indeed GL_RED, so of course the result of the texture lookup is always 1.0 no matter what.
Fixing the shader (use .r instead) gets a dashed line.
I have no idea how that can work anywhere (and even less of an idea why it would be different on intel hw), or maybe glamor uses alpha textures sometimes instead, I couldn't quite figure out how the 8 bit format gets mapped to a gl format in the end...

No idea what's the right component for glamor bugs, though...

Actually I don't see much point keeping two bugs around, now that it's been identified as a glamor issue with the bogus shader texture red/alpha mixup. So let's close this.

*** This bug has been marked as a duplicate of bug 99708 ***

Roland, thanks a lot!

I replaced the .w in the shader with .r as suggested, yet the line still isn't the same as when drawn by the fallback code. I'll hand this over to the glamor people, as we've had a discussion about imprecision before (see fdo#99705).