On Wed, 2017-02-08 at 14:44 +0100, Max Staudt wrote: > On 02/07/2017 09:06 PM, Keith Packard wrote: > > > > Max Staudt <[email protected]> writes: > > > > > OpenGL implementations are allowed to be imprecise in drawing line caps. > > > This patch expands on the original workaround in dc9fa908. > > > > Yeah, finding a way to work around GL differences seems like a good > > idea. In this case, however, I think you're fixing some drivers and > > breaking others -- when drawing with non-idempotent raster > > ops. > > > > Idempotent raster ops are those for which multiple draws generate the > > same result, like GXcopy; hence non-idempotent operations are those > > which do not, such as GXxor. > > What does this mean in practice - is the manual pixel painting the > problem you're seeing here, because it may draw over the previously > drawn lines? > > How does a GXor line draw operation currently work in GLAMOR? Maybe it > would be easier to limit acceleration to GXcopy (which I suppose is by > far the most useful case) and do that case as correct as possible?
On desktop GL, non-GXcopy rops work by setting glLogicOp appropriately. So on drivers that _do_ draw lines like the server's zero-width implementation, the extra points your patch adds for the caps would be drawn twice, and with GXxor that would mean they're painted and then immediately reset. I think, practically speaking, that glamor needs to match fb even along the corner cases where the X spec allows driver-dependent behavior. The simplest way to do this for this case would be to fall down to the mi line code for the case of non-trivial cap style and rop that reads the destination; if done correctly this will still be "accelerated" in that we'll still hit glamor's SetSpans path. A better, but more complicated, solution would be to use the fragment shader to draw the line, where the GL primitive is just some quad that happens to extend a bit past the boundaries of the X primitive so we definitely hit every pixel we need to. - ajax _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
