[cairo] Serious concerns about cairo

[Mike Emmel]

I've been working on implementing the SVG backend for Webkit
on cairo.
I'd like to add that I think the decision to have binary compatibility
was premature at best. A api freeze is even highly questionable.
Cairo is not ready for prime time just yet.
Its usable but there are a number of issues that need to be fixed
before it is a sound 2D library. I know the mozilla team has done
a lot of work for cairo on their SVG implementation but I feel their
is still a lot more todo. As far as gtk goes the internal uses of cairo
don't really exercise the api extensively so I don't consider its use
in gtk sufficient to warrant freezing the api.

My suggestion is that the cairo team ensure that the SVG implementers
have managed to create stable fast complete svg implementations on
top of cairo before its considered stable. If someone is doing pdf or a similar
complex drawing system they should be added as a one of these prime
users.

Now I'm 1000% behind cairo its very useful now and its close to being complete
so I'm not bashing I'm just saying that from my experience so far Cairo is
not quite ready. For example a way to draw paths without copying data must
be solved we can talk real world use cases but basically there is no
technical reason to copy of a object that's has unbounded size just to
draw it. This is a design flaw.

The font support is almost unusable and it only needs a few things to make
it work.

Add one call to get the glyph index for a unicode char.

unsigned long  cairo_glyph_index( cairo_font_face_t* font, unsigned int ucs4);

Add drawing operations at least for ucs2 chars. No one doing advanced text
layout works with utf8 you can't internally. There is no reason not to expose
a set of ucs2 at least text drawing api's they are already used internally.

These two changes will allow me to use cairo for text drawing without
replicating
code that already exists in the library.

Next there is no way to get the current clip path or see if a clip is set.
As with the path there is no function to reuse a complex clip path on
multiple cairo context's.

On the bright side the pattern support is very good and it seems fairly complete
I can create patterns and reuse them effectively except...
There is no way to get the surface back from a pattern that's a surface.
I can get the type but not the surface. Same with all the pattern types.
If its argb I can't get the color or gradient. This means I can't retrieve my
surface from a pattern for further drawing.  Nor is their a matching
create_similar
function for patterns.

This is just some of the issues I've run into and I haven't tried to
replace the built-in
svg support with cairo specific optimization that could take advantage
of cairo context's.
Ideally I should be able to create a cairo context having parsed a svg
page and use
that context for drawing. Even better would be enough of a api to edit
certian aspects.
but we not there yet.


I hope that other people implementing applications that seriously
exercise the cairo api
will speak up and voice there concerns if there is enough feedback
then I hope that
we can really review the state of cairo and consider addressing these
concerns before
considering the library robust enough for general use. If I'm the only
one not happy with
cairo then fine I'll except my position as a whiner but, I just think
people haven't voiced their experiences with the library.

I want to agian repeat I like a lot of things about cairo I'm a big
cairo supporter and I believe
in time it will be the premier 2D library.

Mike