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