Bug 99705 - glamor: Missing pixels at start of some lines
Summary: glamor: Missing pixels at start of some lines
Status: RESOLVED DUPLICATE of bug 106628
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/glamor (show other bugs)
Version: git
Hardware: All All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Depends on:
Reported: 2017-02-07 15:00 UTC by Max Staudt
Modified: 2018-05-23 13:49 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

Test case with line starts rendered incorrectly (1017 bytes, text/x-c)
2017-02-07 15:00 UTC, Max Staudt
no flags Details
OpenGL implementation of the test case (2.29 KB, text/plain)
2017-02-07 15:03 UTC, Max Staudt
no flags Details
Reference output (462 bytes, image/png)
2017-02-07 15:08 UTC, Max Staudt
no flags Details
Broken output (464 bytes, image/png)
2017-02-07 15:09 UTC, Max Staudt
no flags Details
Suggested patch to paint line ends manually (5.37 KB, patch)
2017-02-07 15:23 UTC, Max Staudt
no flags Details | Splinter Review

Description Max Staudt 2017-02-07 15:00:49 UTC
Created attachment 129387 [details]
Test case with line starts rendered incorrectly

(This was originally reported at: https://bugzilla.opensuse.org/show_bug.cgi?id=1021803 )

When drawing lines with GLAMOR, not only line ends but also line starts may not be drawn by the OpenGL backend. This is actually implementation specific:


As far as I can see, both the swrast and the i915 backend will do this on some lines. I have attached an example for X11 that exhibits this problem (the first part of the program in the openSUSE bug report).
Comment 1 Max Staudt 2017-02-07 15:03:35 UTC
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.
Comment 2 Max Staudt 2017-02-07 15:08:13 UTC
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.
Comment 3 Max Staudt 2017-02-07 15:09:40 UTC
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.
Comment 4 Max Staudt 2017-02-07 15:23:00 UTC
Created attachment 129392 [details] [review]
Suggested patch to paint line ends manually

This bug was introduced in xserver commit dc9fa908:


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.
Comment 5 Max Staudt 2017-02-07 15:27:37 UTC
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.
Comment 6 Olivier Fourdan 2017-02-07 15:28:56 UTC
FWIW, patches should be sent to the xorg-devel ML for review:

Comment 7 Max Staudt 2017-02-07 15:52:20 UTC
(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:

Comment 8 Max Staudt 2018-05-18 15:54:40 UTC
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.
Comment 9 Martin Schreiber 2018-05-18 16:37:50 UTC
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.
Comment 10 Max Staudt 2018-05-18 17:42:57 UTC
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?

Comment 11 Martin Schreiber 2018-05-19 06:45:57 UTC
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
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".
Comment 12 Max Staudt 2018-05-22 16:07:54 UTC
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.
Comment 13 Martin Schreiber 2018-05-23 11:49:22 UTC
Comment 14 Max Staudt 2018-05-23 13:49:59 UTC

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

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.