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.
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
