[PATCH 04/13] glamor: Use glamor_program and GL_LINES for 0-width lines

[Markus Wick]

Hi Keith,

here a small summary of my monolog on #org-devel:

Am 2014-05-13 18:02, schrieb Keith Packard:
>> So in the end, I fear we have to add an offset based on the direction 
>> of
>> the line. But this shouldn't be as hard with instancing :)
> No, we just need to move the lines so that they line up with the GL
> pixel centers.

I don't think it's that easy. The required calculations are all done 
with floats, so they don't guarantee to hit the center of the pixel 
exactly. As a small offset from the center of the pixels affects the 
rasterization, this calculation isn't stable.

>> So neither the first nor the last pixel is defined to be
>> overwritten. I doubt X11 defines the same :/
> I don't understand this -- GL defines the lines rasterization rule to 
> be
> identical to Bresenham's algorithm.

I have reread this part of the 4.4 specs for the thrid time now, but I'm 
still unsure what it guarantees.
In the beginning of 14.5.1, it's defined in the way you're using it. But 
in the second part of this section, they relax this specs again:

"""
Because the initial and final conditions of the diamond-exit rule may be 
difficult
to implement, other line segment rasterization algorithms are allowed, 
subject to
the following rules:

[...]

4. If two line segments share a common endpoint, and both segments are 
either
    x-major (both left-to-right or both right-to-left) or y-major (both 
bottom-to-
    top or both top-to-bottom), then rasterizing both segments may not 
produce
    duplicate fragments, nor may any fragments be omitted so as to 
interrupt
    continuity of the connected segments.
"""

And this relaxed version is incompatible with the former one, eg shown 
by a horizontal from A via B to C (all on the center of pixels):
The lines A->B and C->B are defined to overdraw B in the former case but 
defined to _not_ overdraw B in the second case.

However, I've created a test program for the rasterization rules:
http://pastie.org/9175737
i965 results: http://markus.members.selfnet.de/xorg/gl_lines.png
The result should be a gray surface.

I think we have to move the endpoints to get stable + defined 
rasterization results. But this is as easy with instancing or geometry 
shaders.

What do you want to do on devices which doesn't support any of this 
extensions? imo we could fall back to mi or transfer in software :/

> I actually think that GL's semantics are pretty nice here; it defines
> lines to *never* draw the last pixel. The application can explicitly
> draw one if desired. This eliminates another piece of state without
> reducing functionality, which is pretty sweet.

Yeah, this hack is really nice. As both instancing + geometry shaders 
could be implemented in the same way (draw the first but not the last 
pixel), we could still use it. But the code lacks a comment why we just 
add 1 to some coord.