[cairo] Re: Using ADD operator to prevent seams

[MenTaLguY]

On Sat, 2005-03-19 at 11:48, Owen Taylor wrote:

>   A) Are you seriously suggesting that Flash is using full-scene
>      antialiasing techniques? While I can see how they could be
>      useful in an "export" mode, I have a hard time believing
>      that a real-time software renderer would have enough spare
>      horsepower to go that route.

That appears to be the case.  Part of the trick appears to be that "full
scene" means only the objects that intersect the the dirty region.

Generally flash does not have to repaint the entire viewport for every
frame (when it does, you can see the CPU load surge).

>   B) I assume you've investigated the 2-alpha channel arithmetic
>      in PDF and in recent drafts of SVG in some detail. Can you
>      comment whether it has any bearing on your problem?

Yes.  You may recall me alluding to it much earlier in the thread.

I originally thought it might solve the problem, but it's become fairly
evident to me that it's not possible to entirely except in a full-scene
fashion.

If you do the antialiasing incrementally, you just don't have enough
information to determine whether e.g. the background color should
influence the final color of a particular pixel (that will depend on
whether anything is later composited over that same pixel, and what its
precise geometry is ... but the earlier compositing will already have
"contaminated" the accumulation buffer with the background color).

More generally, consider these coverage cases for a single pixel:

  +---------+   +----+----+   +----+----+   +----+----+
  |         |   |    |####|   |    |####|   |    |####|
  |         |   |    |####|   |    |####|   |    |####|
  |         | O |    |####| O |    |####| = |    |####|
  |         |   |    |####|   |    |####|   |    |####|
  |         |   |    |####|   |    |####|   |    |####|
  +---------+   +----+----+   +----+----+   +----+----+
      0%            50%           50%           50%

       A             B             C 
  +---------+   +---------+   +----+----+   +----+----+
  |         |   |         |   |    |####|   |    |####|
  |         |   |         |   |    |####|   |    |####|
  |         | O +---------+ O |    |####| = +----+####|
  |         |   |#########|   |    |####|   |#########|
  |         |   |#########|   |    |####|   |#########|
  +---------+   +---------+   +----+----+   +---------+
      0%            50%           50%           75%

  +---------+   +----+----+   +----+----+   +---------+
  |         |   |####|    |   |    |####|   |#########|
  |         |   |####|    |   |    |####|   |#########|
  |         | O |####|    | O |    |####| = |#########|
  |         |   |####|    |   |    |####|   |#########|
  |         |   |####|    |   |    |####|   |#########|
  +---------+   +----+----+   +----+----+   +---------+
      0%            50%           50%           100%

(Here, 'O' is a "covered by" operator)

If you "flatten" the geometry into a single scalar coverage value
(regardless of whether or not it is segregated from the alpha mask
proper) at each step, it's impossible to distinguish these three cases. 
The necessary information is simply lost.

> I think it would be cool if you took Dave's patch that Carl referenced
> and did some experiments with it... having some hard data about what 
> image quality is achievable with what overhead would be useful.

That sounds good.  Where can I get Dave's patch?

> P.S. - You mentioned "rendering at a higher resolution and filtering";
>    an alternate approach is, of course, to render multiple times and use
>    an accumulation buffer. Is the overhead of walking the SVG tree
>    (or of converting paths to trapezoids) high enough to make that
>    prohibitive?

Depends on the nature of the document.  You're certainly trading CPU
time for memory if you do that, which is probably not a good tradeoff
unless the document is very simple or the output image size is very
large.
-------------- 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/db00e554/attachment.pgp