[cairo] Serious concerns about cairo

[Robert O'Callahan]

On Sat, 2006-09-23 at 16:52 -0700, Mike Emmel wrote:
> Now as far as Mozilla goes I've looked at their SVG implementation
> its far form complete and it sounds like they have already made a lot
> of contributions. My orginial email suggested waiting till after they get
> a reasonably complete implementation done before considering a api
> freeze. Have they told you they are far enough along that they feel like
> cairo will meet there needs ? I don't think they have done the
> animation support yet for example.

I don't think animation creates any special requirements for cairo,
except for performance. Performance requirements could turn into API
requirements, perhaps. (E.g. it might become necessary to be able to
cache pretesselated paths.)

>   I think I've actually got a more
> complete implementation they
> they do at the moment mainly of course because I could build on the
> changes the y have already submitted.

What new cairo requirements have you discovered? We have RGBA->luminance
conversion (for SVG masking) and filters on our wish list, I'm not sure
what else.

For paths, we convert SVG path data to our own compressed internal
representation and then replay the paths through cairo every time. I'm
not sure if it's worth avoiding just the replay step. I think actually
tesselating and filling paths is way more expensive.

> I don't disagree that there is not a need for a companion library that provides
> a more extensive api but that's not a good argument to not provide a
> more complete basic api. Adding the ability to get a glyph index and
> ucs2 char support will cover 99% of the text rendering needs.

This may be true if "text rendering needs" are limited to the crappy job
that most applications currently do. Applications *should* be handling
kerning, ligatures, shaping and combining characters. That inclines me
to stick to "just use Pango" and not make it easy to do crappy text
rendering :-).

> For the remaining 1 percent good bidi libraries already exist to
> handle part of the problem.

Yeah, we handle bidi at a higher level so it doesn't bother us here.

Rob