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

[Keith Packard]

Markus Wick <markus at selfnet.de> writes:

> iirc this will add the offset of (0.5,0.5) to the position?

Right, the call to glamor_set_destination_drawable adds this to make the
pixel centers line up correctly.

> 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.

> Without this offset, the position of this line isn't defined for 
> vertical or horizontal lines.

Of course, just like points.

> 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.

> First, you aren't allowed to access a write_only mapped buffer (v) in a 
> reading way.

Eric caught this as well.

> Second, I'm not familiar with the X11 line rasterization, but I doubt 
> that this flag is just for painting an additional pixel on the right 
> side after the last one. eg nothing happens for lines from right to 
> left, and it will look quite funny for lines from top to bottom:
>
>    X
>    X
>    X
>    XX

No, GL defines the line to *never* include the last coordinate in the
line, so the direction of the line doesn't matter here, the only
requirement is that it be two pixels long so that the first pixel (the
one at the end of the previous line) does get drawn.

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.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140513/c7307165/attachment.sig>