[cairo] Dia as a new Cairo testbed
Hans at Breuer.org
Tue May 25 05:32:00 PDT 2004
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  export filter based on Cairo. The source of it is already in gnome
> > cvs, it even is integrated in the *NIX build process : ./configure
>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
>(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
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 ...
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it. -- Dilbert
More information about the cairo