Bug 99705

Created attachment 129388 [details]
OpenGL implementation of the test case

Same thing, in plain OpenGL.
This uses GL_LINE_STRIP instead of GL_LINES in the X11 version via GLAMOR.

Created attachment 129390 [details]
Reference output

This is what the output should look like when rendered correctly.

In this case, I have used Xephyr *without* GLAMOR.

Created attachment 129391 [details]
Broken output

This is what the output looks like when GLAMOR is used through Xephyr -glamor or when using the modesetting DDX on Intel.

A variation is seen when using LIBGL_ALWAYS_SOFTWARE=1 or Xephyr -glamor_gles2 where only one corner is missing.

Created attachment 129392 [details] [review]
Suggested patch to paint line ends manually

This bug was introduced in xserver commit dc9fa908:

  https://cgit.freedesktop.org/xorg/xserver/commit/?id=dc9fa9080a1cb994b4e54a341d2245f442dac576

The code has a special provision to paint the line ends by adding one extra line of one pixel at the end. This assumes that the last pixel then won't be drawn.

However, as implementations are allowed some slack in implementing both line starts and ends, this is inaccurate.


I have attached a patch that paints the start and end pixels manually instead, using GL_POINTS.

I'd be grateful for a review as to whether painting *all* edge pixels, except the very last, is the right thing to do in glamor_lines.c in the CapNotLast case.

To clarify: The above patch is on top of the commit that introduced the broken rendering, not on top of master. The problem is still present in current git master though.

FWIW, patches should be sent to the xorg-devel ML for review:

https://www.x.org/wiki/Development/Documentation/SubmittingPatches/

(In reply to Olivier Fourdan from comment #6)
> FWIW, patches should be sent to the xorg-devel ML for review:

Whoops, thanks for reminding me. Done:

https://lists.x.org/archives/xorg-devel/2017-February/052624.html

Seems like interest has faded, both on xorg-devel as well as downstream, so let's close this as WONTFIX. Anyone objecting can re-open it.

Why do you think the interest has faded?
A line drawing function which sometimes paints the endpoints and sometimes not is useless IMO. Because "modern" desktop environments mostly "shift around big pixel areas only" doesn't mean that Linux should not provide fast and correct working line drawing primitives IMO.

Thanks for replying, Martin!

The reason why I assumed that interest has faded is that after more than a year, neither upstream nor you commented on this any further. Neither here nor on xorg-devel. I'm afraid I didn't CC you on xorg-devel - the thread is linked in Comment 7, I hope that helps in case you haven't followed it.

The reason for me wanting to close the bug is that I am leaving my role as a graphics stack developer (at least for now), so I am trying to close tickets I'll no longer be able to answer to.

Martin, would you mind opening a new bug with you as the reporter, so we can close this bug as a duplicate of that?

Thanks!

I am no graphics expert so I can't really follow the thread but I also think that driver bugs should be fixed not "circumvented". If the last point of a line is never painted one could adjust the line endpoint accordingly. MSEgui does so on Windows GDI32 back end in order to achieve consistent behavior on all supported platforms.
I am the author of the cross platform toolkit MSEide+MSEgui which uses X11 on Linux and FreeBSD where users sometimes find bugs in their X11 environment.
One of the worst which has not been touched since years is
https://bugs.freedesktop.org/show_bug.cgi?id=84253
The only thing I can do is to report issues and to hope that a kind X11 expert takes pity on a not mainstream product or to give up on X11 and hardware acceleration completely and to draw all pixel by pixel myself as probably other toolkits do.
The problem with the Glamor line ending bug is that my PC which reproduced it died and I currently don't have a machine where I can do tests. I fear if I open a new bug report myself it will be closed in a blink of an eye because of  "insufficient response from reporter".

I've looked through the old email thread again, and there is clear evidence for your bug. So I don't see your bug being closed for insufficient evidence.

It has been suggested to either fall back to pure software rendering, or to re-implement the line drawing acceleration as a shader, so there are clear options to solve the bug, too.

On the other hand, I'm leaving the X developer world (at least for now), so I'd appreciate if we could close this bug - unfortunately, I can't assign you as the bug creator, so the only way to silence it is to have you open a new bug to replace it. And that would be the correct way to do it - after all, you are the actual reporter of this bug.

It's important to point to the email thread I linked in Comment 7, as well as to this bug and the downstream openSUSE bug. I'm happy to assist you in this if you like.

Here:
https://bugs.freedesktop.org/show_bug.cgi?id=106628

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