[cairo] Dia as a new Cairo testbed

[Hans Breuer]

At 03:05 25.05.04, Keith Packard wrote:

>Around 0 o'clock on May 25, Hans Breuer wrote:
>
> > To get an educated opinion about current abilities of Cairo I've written a
> > Dia [1] export filter based on Cairo. The source of it is already in gnome
> > cvs, it even is integrated in the *NIX build process : ./configure 
> --with-cairo
>
>Cool.  We'll try to figure out where the remaining problems are. I tested
>the .svg file with the cairo-based 'xsvg' program which generated different
>output.
>
>         http://keithp.com/~keithp/download/render-test.html
>
>(The images in this version don't appear at all because the svg-cairo
>library doesn't handle them yet).
>
> > The arc drawing is completely bogus. [Doing a simple cairo_arc()
> > produces arcs mirrored against the horizontal axis and all my tries
> > with cairo_arc_negative() and angle juggling have failed, too.]
>
>I think you haven't quite got the arguments for these functions figured
>out; xsvg draws this figure correctly.

This is what I think, too. At first glance it appeared to be very simple to 
doe the transition from Dia's renderer API to Cairo - both appear to use 
the parameters : two angles, the center point and a radius (infact Dia has 
two of them, but I've just ignored the second one;).
My first attempt did produced a stack overflow in Cairo, cause I missed to 
translate from DEG to RAD. Further attempts failed cause I could not figure 
out how to fix the different interpretations of arc directions ...

> > Linestyle in bezier lines are apparently not supported yet
>
>Yup.  It's not a huge amount of work, but it is yet to be done.

This is what I expected ;-)

> > Image rendering is not as good as expected (At least I would
> > expect it to reproduce similar quality as in the pixbuf case
> > when using CAIRO_FILTER_BEST).
>
>We're just using bilinear interpolation.  Anisotropic filtering would
>generate better results.
>
> > Rendering of alpha images is completely broken. Maybe caused by
> > not properly using the Cairo Operator.
>
>Perhaps this is a confusion with the premultiplied alpha format which
>cairo uses.  libart uses non-premultiplied alpha (I'm pretty sure).  This
>may also be causing troubles mentioned above?

So there needs to be even more conversion in
plug-ins/cairo/diacairo.c:draw_image()

As an API user I'd rather prefer to do less conversion than more. One thing 
which took some to get right was the expectation of cairo to get pixels 32 
bit aligned even when I pass CAIRO_FORMAT_RGB24 
to  cairo_surface_create_for_image(), another thing is it apparently 
expecting BGR instead of RGB.
And yet another thing, that Cairo doesn't make the copy it needs and 
transforming/copying to it's native format itself, but instead insist on 
keeping and free()ing _my_ data ;-)

> > Text rendering is known to be limited in Cairo (the so called 'toy api'
>
>If dia uses pango for text rendering, we should be good to go once there's a
>cairo backend for pango.

Dia uses Pango for it's text rendering - at least up to the point where the 
Pango API gets too limited to allow what's required. In that case it uses 
the Pango backend (FT2 or to some extent win32) directly. Where I prefer 
the latter cause of performance and just-on-font-engine reasons. But that's 
a different story ...

Thanks,
         Hans


-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert