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

[MenTaLguY]

On Fri, 2005-03-18 at 10:49, Carl Worth wrote:
> By "render this", I'm going to make the simplifying assumption that
> you'd like to see cairo code to render the intended figure, (as
> opposed to cairo code to render the sliced up pieces as presented in
> the SVG file).

"By 'fly there', I'm going to make the simplifying assumption that you'd
like to see a method to go really fast from here to the intended
location, (as opposed to a method which involves actually leaving the
ground and travelling through the air to get there)."

:)

I really needed some way to render the pieces as presented in the SVG
file.

The given solution's really clever, but it doesn't really solve the
problem I need to address with cairo:  being able to render arbitrary
user-created documents without potentially introducing seams.

> I don't claim that this little code sample solves all the problems
> with things that a user might do in inkscape or with SVG. But, I hope
> I've demonstrated that it's worth investigating solving problems in
> ways more sophisticated than "turn off antialiasing".

I realize it's unintentional, but that still hurts.

I've been aware of the seams issue for the past four years (it's not
specific to cairo but common to all renderers that manage partial
coverage in this way), and have been actively working on solving it for
such renderers for the past one and a half to two years because of my
involvement with Sodipodi/Inkscape.

I've been through quite a number of sophisticated potential solutions,
but in the end they all reduced to:

 1) write my own renderer using a different approach for dealing with
    partial coverage (because the solution already involved most of the 
    computation you'd need for rasterization anyway...)

 2) modify an existing partial-coverage-simulating renderer (e.g. cairo)
    so that partial coverage simulation can be turned off; antialiasing,
    if required, can be achieved by rendering at a higher resolution
    and filtering

If Owen and Solerman keep developing their proposed approach for using
your technique, they'll most likely discover that the only really
efficient way to populate the BSP trees is to tesselate the
strokes/fills/text up front (rather than trying to operate on masks).

Once you have a BSP tree full of triangles/trapezoids, you may as well
rasterize directly from that.  Might be able to leverage pixman, but
there'd be no point to using cairo proper anymore really.

[ One of nathan's suggested solutions to me a year or so back was to
write a BSP-based renderer in fact. ]

There are some similar issues with Bill's suggestion that involved his
proposed aliased_lineto as well.  At bare minimum it'd require
pre-tesselating fills.

Modifying cairo's image backend so it can optionally draw shapes without
trying to simulate partial coverage using the alpha channel is
comparatively trivial, though.

It's the simplest solution I've found so far, and unlike most solutions
from category 1 doesn't require building a massive extra in-memory data
structure for the entire document at once.

> And, it may not be totally unrealistic for a user to approach this
> drawing problem by using clipping in a way similar to what I've done
> here.

Manually constructing nontrivial documents that way requires preplanning
and a certain level of mathematical rigor that I think is unrealistic to
expect of a graphic artist who is just incrementally experimenting to
draw something that looks good.

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.

You can redraw the sliced-up version of the star-and-ring in e.g.
Macromedia Flash, and not see any seams (I just tried it).  I think the
same is generally true of Adobe products as well (I don't own a copy of
Illustrator anymore, but I don't recall seam issues there either, at
least not for bitmap export).

[ It might be an interesting experiment to render the sliced-up
star-and-ring using cairo's PDF backend and see whether Adobe Acrobat
will show seams or not... ]

But Inkscape's audience of graphic designers is going to expect a
renderer that won't produce seams in final bitmap output.  I'm not
suggesting that cairo has to always avoid seams -- seams aren't as big a
deal for interactive use, which is why Adobe's SVG plugin can get away
with allowing them -- but avoiding them would at least need to be
possible for e.g. "bitmap export".

So far I keep getting presented with solutions that imply reimplementing
large portions of cairo on my own, or forcing users to go through
painful contortions to work around renderer issues.  I was kind of
hoping we wouldn't have to write our own renderer from scratch yet
again[1].

Subject to the normal code review process, would you be willing to
accept the image backend patch if I wrote it?

Alternatively, how easy is it for a client application to provide its
own cairo backend?

-mental

[1] Inkscape's current renderer, livarot, also has problems with seams
about which we get user complaints, but it's too ugly and fragile to
modify, which is part of the reason I had been so intent on switching to
cairo.
-------------- 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/20050318/5502cac1/attachment.pgp