Search cairo mailing list archives for the threads with subject "avoiding seams"...

Lots of talk about it on the mailing list...

Perhaps we should be doing what Adobe Flash is doing, then, and supersampling
the rasterised images (FSAA)?

Someone noted that when analysing monochrome images with Adobe Flash there were
16 distinct colours in "High Quality", 4 in "Medium Quality" and 2 in "Low
Quality", reflecting 4x, 2x and no oversampling, respectively.

With a hardware accelerated rendering backend, this would be more forgiving -
but I think it's important to a lot of people that they have slow, accurate
renderings vs. fast, inaccurate renderings.

(In reply to comment #2)

> but I think it's important to a lot of people that they have slow, accurate
> renderings vs. fast, inaccurate renderings.

Really?  Those who care are welcome to do supersampling themselves.  Cairo
allows that, and even has got the push/pop group API that helps a lot with that.

(In reply to comment #2)
> Someone noted that when analysing monochrome images with Adobe Flash there were
> 16 distinct colours in "High Quality", 4 in "Medium Quality" and 2 in "Low
> Quality", reflecting 4x, 2x and no oversampling, respectively.
> 
> With a hardware accelerated rendering backend, this would be more forgiving -
> but I think it's important to a lot of people that they have slow, accurate
> renderings vs. fast, inaccurate renderings.

Note that for images not affected by the "seams" problem that getting at most 16
levels of antialiasing rather than the current maximum of 256 level would
definitely be much less accurate. So it's not easy to make decisions about which
is the correct approach to take inside a library like cairo where there's not
much information available, (for example, cairo only sees one object at a time).

Also, as mentioned above, it should be possible to do implement an FSAA approach
above cairo by rendering to a larger-size image and then doing a filtered
downscaling. (Though if downscaling by more than 2x one will want something
better than the current filter in cairo's implementation.)

So I really think this particular bug should be pushed back to the librsvg code,
or else to whatever is being used to generate the original SVG content that
makes assumptions that drawing identical geometry in a different color is
sufficient to entirely obscure the previously drawn content. I don't think the
SVG specification makes any guarantee close to that, (the strongest language I
could find in the specification allows for a conforming implementation to draw
things "within 1 pixel" of the ideal geometric result, for example).

-Carl

PS. Also note that getting 16 different levels would require at least 15 samples
per pixel, not 4.

It seems I misunderstand the terminology, then. I thought 4× supersampling of a
2-dimensional image effectively increased canvas dimensions by 4 times in both x
and y dimensions (giving you 16 samples).

That's what I meant, anyway.

Also I think perhaps there is a distinction between the terms "accurate" and
"quality". I'd say an image with no anti-aliasing in its current state, is 100%
accurate but low quality. An anti-aliased image would be almost accurate but
high quality. Again, maybe I am using the wrong words.

Thanks

Is it actually possible to disable anti-aliasing in the Image backend?

This is basically a blocker bug for Inkscape in that it can't render a pixmap
properly.

The problem only goes really away if you actually disable anti-aliasing
completely. Anything less is just lessening the problem without removing it.

That's what cairo_set_antialias is supposed to do.

Added "reference implementation of FSAA" to the TODO list.