Using ADD operator to prevent seams (was: Clarification Re: [cairo] Mac Tiger Core Image)

[MenTaLguY]

On Sat, 2005-03-19 at 11:24, Carl Worth wrote:
> If you did the antialiasing in the application, it still sounds to me
> like you'd be ignoring cairo. So that doesn't sound ideal. And my gut
> feeling is that the memory requirements of this approach would be
> prohibitive, (at least to get to the same quality in rendering). But I
> don't have solid evidence to back that feeling up.

As discussed on IRC, it appears that Macromedia Flash, at least, does
use this approach and apparently even 4x4 "supersampling" is considered
sufficient quality for graphic design purposes.

[ Having looked at the histograms for various opaque figures rendered by
Flash at the high quality setting, there are always sixteen discrete
steps of coverage. ]

Anyway, in real world use the memory requirements do not appear to be
prohibitive.

> David Reveman posted a patch sometime back that allows the user to
> select the format of the intermediate surface used within cairo to
> hold the shape. It's CAIRO_FORMAT_A8 by default and with the patch the
> user can set it to CAIRO_FORMAT_A1. That covers the "disable
> antialiasing" part, (and the patch is really tiny). But, as I said,
> that still puts a burden on the application in order to get
> high-quality results.

I'm still a bit fuzzy on how cairo's rendering pipeline works.  This is
just for the shape masks, so it won't affect pattern translucency?

If so that's ideal and even easier than what I had been considering.

> Well, part of an answer might be that if the artist can see the seams
> during the incremental experiments, then the artist can do whatever it
> takes to get rid of them.

Sometimes whatever it takes would be a bit extreme -- consider e.g. a
large, complex celtic knot pattern laid out on a hexagonal grid.

Also, using ADD specifically does require a version of SVG that supports
explicit use of the porter-duff operators, which means it's not going to
be usable at all for SVG authors until SVG 1.2 becomes widely supported.

> > Besides that, the seams are an avoidable rendering artifact, not part of
> > the data.  Any decent renderer should at least provide some means to
> > avoid them.  In fact, renderers used by professional design software
> > generally do not use alpha-based partial coverage simulation precisely
> > because of these kinds of artifacts.
> 
> Do you have a recommendation for what cairo should do instead?

Yes... for the use cases where avoiding seams IS critical, I think I do
finally have a "pure cairo" recommendation.

I realized this morning that there is a common characteristic to all
antialiasing methods that avoid seams:  they require knowledge of the
entire composed image before they can produce an antialiased result. 
This is true of "supersampling", the BSP tree approach, and all the rest
I have ever encountered.

This suggests that any "non-seam" renderers should exist as separate
cairo backends which compose the image in some intermediate form (e.g. a
non-antialiased scratch buffer, or a BSP tree), and then produce an
(antialiased) result only upon showpage.

I think the "supersampling" renderer would be the best to implement
first, as it's extremely simple, and I'm not entirely convinced that (in
this particular context) the BSP approach is viable memory-wise[1].

As for the existing backends, I'm not sure it's possible for them to
avoid seams in the general case, at least for those that perform
compositing themselves.  With e.g. the PDF/PS backends we are of course
at the mercy of whatever PDF/PS renderer happens to be used.

> I would be happy to see a patch that really solves the problem. We've
> got the "disable antialiasing" thing already, and I'll probably be
> convinced to commit it eventually. But, for almost every problem for 
> which it has been proposed, (not just the current topic), I don't
> see it as providing a complete solution.

It seems to be an important building block though.

I do also notice that Macromedia Flash explicitly offers non-antialiased
bitmap output as an option.  I think Illustrator does as well.

Though I've not had occasion to use it myself, that does seem to suggest
it's an important capability for some graphic artists.  If Cairo doesn't
offer it we're back to writing custom renderers for Inkscape again.

-mental

[1] One reason being that cairo patterns are mutable (unless I'm
mistaken).  Because the BSP renderer defers actual rendering, you must
copy the current pattern to a separate immutable pattern buffer for each
set of trapezoids that are added to the tree.  Some sort of
copy-on-write mechanism for patterns might help, but that's a far more
aggressive proposal than the CAIRO_FORMAT_A1 thing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050319/99bc73be/attachment.pgp