[Cairo] AA-Artifacts during/after gameoflife

[Carl Worth]

On Nov 18, Christof Petig wrote:
 > I thought that drawing a red Circle on white, then a white circle of 
 > same size and then a black circle should ideally give the same result as 
 > drawing only a black circle (but with AA it doesn't).

As they say, that's life. With anti-aliasing, even "opaque" objects
aren't really as there is some blending with the background on the
edges.

 > And this was the problem I suspected - clearing the canvas between
 > game of life cycles is cheating IMHO. [Though it will probably good
 > enough for most applications.]

I did say the current code is not optimal, didn't I? ;-)

In general, the application does need to redraw everything within a
given region, but it's definitely not necessary to redraw the entire
canvas just to fix up one damaged area. This is the motivation behind
the proposed cairo_surface_clip_* functions.

 > But perhaps repeatedly drawing the same text (or the same line) should 
 > not darken the corners further.  Possible with cairo?

I don't think there's a general solution for this. When a drawing
operation is performed, there will almost always be some blending with
the background pixels. After the drawing operation, the results just
become a part of that background. Subsequently, cairo has no idea if
background pixels come from the "same line" or not.

For some more limited cases, including repeated compositing of a brush
with overlapping copies of itself, (but not including the compositing
of the result with a background), the Conjoint operators provided by
Render do provide the desired semantics. However, we've recently
decided to drop support for these operators from cairo as most
backends will not support them.

On a somewhat related note, when we discussed similar issues with text
a while back, there was a proposal for two calls, cairo_text_begin and
cairo_text_restore, where drawing operations between the calls would
be pre-composited on a temporary surface, and only the result would be
composited against the background.

I think we may want a more general mechanism for doing that with more
drawing operations than just text. And I think the same result is
possible already with a manually created surface, so we'll probably
just want a couple of convenience functions, (cf. discussions on
push_group/pop_group).

 > All in all I was told (on gtk-devel) that semitransparent widgets need 
 > cairo.

Ah, that may be. All I was trying to get across is that there's no
need to wait to start coding Gtk+ programs with cairo.

Happy hacking!

-Carl