[cairo] Serious concerns about cairo

[Mike Emmel]

On 9/24/06, Robert O'Callahan <rocallahan at novell.com> wrote:
> 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.)
>
This is exactly what I'm thinking about doing.

> >   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.
>
To be honest I'm not sure I've not yet got to the point of working back
up from the canvas like api in Webkit to the svg elements.
One thing that would be nice might be arrays of text runs.

But talking about text is forbidden :)

I'm sure there is something in animation. Its more I think your code
get some significant performance gians from having cairo calls that
map closer to svg concepts and allow you to use internal data structures.
Maybe the svg id concepts would could be useful ?
Also there are the filters which I've not looked deeply into but they
look interesting.

In any case I plan to eventually spend some time looking to see
if there are any potential optimizations.


> 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.
>
Hmm have you tested this ?
And would you mind keeping my private email and let me know if you have
test results.  And whats wrong with presellating the paths.
And of course does the new  tesselator may change the results signifcantly.
The fastest approach is to have the paths tesselated IMHO.
Do you see reason to not store in tesslated format ?

> > 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 :-).
>
Yeah I've got long posts on this but I've come around to just rerouting
the toy api back through a layout engine thats whats done on the OSX/Windows
ports and then reconsidering the layout engine.
For now I think I'll dig deeper into ICU yet one more time and see if
I can pull out
a reasonble subset  from the monster. I'll keep watching mozilla.


> > 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
>
>
Want I want is a really smalll layout kernel with all the data as XML files
and probably move a lot of the conversion stuff to javascript so I
only pick it up
if I use a local.  I think its possbile to split things up so your
kernel is small
and the bulk of the language specific stuff is in XML files and
javascript objects.
Adding and removing language support would then be simply a matter of xml files.
ICU's data is already in XML format.

Do you see any obvious reason why a lot of code could not be in javascript ?

You may want a companion native version for your main language but thats fine.
Its would be a upcall from C anyway.