Experiment with disabling ant-aliasing (was: Re: [cairo] Re: Notes on cairo/win32)

[Carl Worth]

On Wed, 12 Jan 2005 17:10:09 -0500, "Dimitrie O. Paun" wrote:
> On Wed, Jan 12, 2005 at 01:09:02PM -0500, Carl Worth wrote:
> > No, and it shouldn't be too hard even, (just a matter of selecting an
> > A1 buffer internally when drawing shapes to the mask). People wanting
> > pixel-perfect emulation have asked for this in cairo, and I said I
> > would try implementing it. It just hasn't bubbled up as a
> > high-priority task for me yet.
> 
> Excellent. I think being able to avoid AA output would be useful
> in general, not just for Wine/Mono.

One use that I do care quite a bit about is for printing. We don't
need anti-aliasing for high DPI prints and it likely causes problems.

Yesterday, I decided to take a closer look at what changes would
actually be required in the implementation. We're pretty much talking
about the outlines of objects from cairo_fill/stroke, right?  Those
all go through the backend's composite_trapezoids call. Looking at
cairo_xlib_surface.c we see it call XRenderCompositeTrapezoids with:

	XRenderFindStandardFormat (dst->dpy, PictStandardA8)

That tells RENDER to use an intermediate 8-bit alpha channel to
pre-composite the trapezoids into a mask. We can change that to
PictStandardA1 to use a 1-bit mask. I just tried this and I did get
non-antialiased results. They're really foul though at typical display
resolution though. Take a look at cairo-spline here:

	http://cairographics.org/~cworth/images/cairo-spline-ugly.png

Note the little red "circles" now look more like octagons. One could
actually do much better non-antialiased rendering than that by
carefully designing around it, but I would find it very hard to get
excited about work like that.

I am planning to add some optional device-pixel snapping support to
cairo, and that will likely help naïve graphics in both antialiased
and non-antialiased versions.

It's not obvious to me that one will automatically get pixel-perfect
results matching some other window system by using this approach.

The changes for other backends should be similar. Oh, and long-term we
don't want to rely on RENDER to do pre-compositing anyway. The problem
is if you send too many trapezoids then XRender breaks it up into
multiple requests and you only get pre-compositing on each chunk,
(meaning seams between them). The long-term answer is to do our own
computation of the shape mask, and with that, we can centralize the
decision of what format to use for the mask.

The final question then is what the API to select this mode should
look like. Selecting the format for the internal shape mask? Selecting
the number of bits of antialiasing? A boolean selection?

-Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050114/7b56fc9b/attachment.pgp