[cairo] Switching to Evas Canvas over LGPL

[Carl Worth]

[My apologies if anyone gets this twice. I seemed to have botched my first attempt.]

On Mon, 16 Aug 2004 11:53:04 +0200, "Turner, David" wrote:
> > Explain what Cairo does that Evas does not -- if anything.=20
> 
> OK, I'll bite :-)

David,

Thanks for the overviews of these four efforts. You provided a more
thorough/accurate summary of them than I could have, and I hope your
description helps people understand things better.

I'd like to fill in just a couple of minor details with respect to
cairo.

>   At the moment, Cairo is _massively_ slow at pixel rendering
>   compared to other vectorial libraries like libart or anti-grain.

Quite likely. Though I have heard some favorable anecdotes that cairo
was "fast enough" or even "faster than libart" in some situations, I
have no evidence to suggest that this is the general case. Also, cairo
performance does depend strongly on the backend being used. The glitz
backend (using OpenGL) is remarkably fast when given the right
combination of hardware and drivers.

>   I know this is because it tries to deal with extremely-high
>   quality rendering.

I would say that the reason is that the development effort has so far
focused on extremely-high quality rendering, and not yet on
performance. Interestingly enough, the most interesting work I feel
we've been doing in cairo, (high-quality, robust stroking and
tessellation), seems like it won't be horribly slow. This benefit comes
from prior research by research by Lyle Ramshaw, John Hobby, and others
that shows efficient ways to get the right answer.

One piece of the pipeline in cairo that is currently much slower than it
needs to be is the software for image transformation and compositing,
(whether in libpixman or in the Render extension of the X server). Keith
has never intended the code that's there now to be more than a reference
implementation, and has recently outlined a plan for making it much
faster. That's a nice, separable task so that a motivated developer
could jump in and make some very useful contributions. If anyone has
interest, please let us know.

>   Cairo has a state-full API. It doesn't support hit-testing
>   for the moment.

I did write a couple of functions, (cairo_in_stroke and cairo_in_fill)
that can be used to test if a point is within the region that would be
covered by stroking or filling the current path. These work by carrying
the stroke or fill operation through the tessellation phase and then
testing against all of the generated primitives.

A more complete system would do faster approximations first. It's quite
likely that a higher-level canvas library would want to do bounds
testing, etc. itself even before handing data to cairo.

Hope that helps,

-Carl