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

[David Reveman]

On Fri, 2005-01-14 at 11:40 -0500, Carl Worth wrote: 
> 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

I've put together two patches that should accomplish this. One is for
pixman to support A1 bitmap masks and the other adds a shape_format
attribute to the cairo graphics state and allows the user to switch
between aliased and anti-aliased geometry with the following function:

void
cairo_set_shape_format (cairo_t *cr, cairo_format_t format);

format being CAIRO_FORMAT_A1 for aliased geometry and CAIRO_FORMAT_A8
for anti-aliased geometry. Default shape format for a newly created
context is CAIRO_FORMAT_A8. cairo_format_t could eventually be replaced
with something like:
typedef enum {
  CAIRO_SHAPE_FORMAT_A1,
  CAIRO_SHAPE_FORMAT_A8,
  CAIRO_SHAPE_FORMAT_VRGB,
  CAIRO_SHAPE_FORMAT_HRGB,
  CAIRO_SHAPE_FORMAT_VBGR,
  CAIRO_SHAPE_FORMAT_HBGR
} cairo_shape_format_t;


This should work for xlib, xcb and image (png, ps) backends. However,
there seems to be some bug in libpixman, which makes it very unstable
when using bitmap masks. I'll probably look into this more closely
later. xlib and xcb backends seems to be working fine.

-David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libpixman-trap-format.diff
Type: text/x-patch
Size: 1363 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050114/c7475875/libpixman-trap-format.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cairo-shape-format.diff
Type: text/x-patch
Size: 11400 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050114/c7475875/cairo-shape-format.bin