[PATCH xserver] glamor: Paint first and last pixel of lines

Max Staudt mstaudt at suse.de
Wed Feb 8 13:44:26 UTC 2017


On 02/07/2017 09:06 PM, Keith Packard wrote:
> Max Staudt <mstaudt at suse.de> 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?


> I'm not sure what we should do here; there's no requirement in the
> protocol that we do anything at all as the server is allowed to draw
> pretty much whatever it wants for zero-width lines.

The X11 client developer who filed the openSUSE bug

  https://bugzilla.opensuse.org/show_bug.cgi?id=1021803

is confused because the software fallback and the GLAMOR version produce
different results. IMHO, since the Xorg server's software fallback
tends to be regarded as the reference X11 implementation, we should try
to emulate that as closely as possible.


I have to agree that this is a funny situation. Neither X11 nor GL are
rigidly specified, yet we're connecting them :)


> If you've found specific problems with Mesa drivers, I'd suggest we
> actually go fix those instead of working around them in the X
> server. The GL spec seems pretty clear in what it wants, and I think
> that aligns with what the X server currently expects.

I'm not sure, do you think this is a problem in the OpenGL drivers used?
It seems within the GL spec, so I'd say Mesa is not the right thing to
fix.

Given that there are plenty of binary drivers, and that we may end up
doing GLAMOR in an Xwayland session, I think we should aim for GLAMOR
being as precise as the fallback. Or disable the acceleration (we could
make it a configuration option). Most modern clients just display images
anyway, and the few remaining ones probably expect rather precise output
from Xorg as a rasterizer.

Consistency is important, as anything else can severely confuse users
and debugging developers alike - I think I've once seen that last line
pixel (which you use to draw the cap) being drawn on some backend. Now
that's a weird graphics glitch! And we can avoid it by setting the cap
pixel manually. Though as you say, only in case of GXcopy.


Max



More information about the xorg-devel mailing list