[cairo] Re: [Librsvg-devel] Porting librsvg to an Embedded Platform
cworth at cworth.org
Thu Oct 5 09:05:06 PDT 2006
[I'm taking this discussion over to the cairo mailing list now, since
the content is no longer librsvg-specific. Please feel free to drop
the librsvg mailing list from any follow ups.]
On Wed, 4 Oct 2006 14:22:02 -0400, "Dominic Lachowicz" wrote:
> > me the minimum RAM and HD requirements for librsvg? Also, would it be
> > possible to port librsvg and Cairo to Fixed-Point?
The cairo API accepts floating-point numbers. The first thing it does
with them is run them through a floating-point transformation matrix,
(a few multiplies and adds) and then convert them to fixed-point. From
then on, all arithmetic in cairo really should be fixed-point, but the
tessellator in all released versions actually converts _back_
to floating-point and tessellates in floating-point.
> Of course it would be possible (provided that there was no API/ABI
> breakage). There are some patches already that port Cairo to fixed
> point. I don't know how complete they are, or what their chances of
> being merged upstream are.
There are various patches, and we are working to get them all
integrated. Here are some of the things that have been worked on so
* Skip the floating-point transformation matrix if it is an identity
matrix, (this patch has been shown to provide a large improvement on
embedded systems). I like the concept of the patch, but would like
to see it be cleaned up a bit before landing, (as discussed on the
cairo mailing list).
* Use a much faster method for converting floating-point to
fixed-point, (taking advantage of IEEE floating-point representation
when possible). There are patches that have been proposed to do
this, but none of them yet have the configure-time checks to ensure
that the method can reliably be used. There is also some open
discussion about which rounding mode we want, but I'm guessing it
really won't matter down at the level of the fixed-point sub-pixel
* Fix the bug of converting back to floating-point for tessellation.
My new tessellator patches fix this. They are not yet merged to the
main branch of cairo, but I am planning to do this within the next
week or so after fixing it to use 64-bit intersection code rather
than 128-bit intersection code when possible.
* Something else that will help is to change from a 16.16 fixed-point
representation to something like 24.8. People have been wanting this
to have a larger range for the integer portion anyway. But I really
want this now, since without this change the 128-bit intersection
code will almost always be necessary.
So once all that is in place there should be some huge improvements to
cairo performance on embedded systems without hardware floating-point
I'm looking forward to doing some measurements on my Nokia 770 to see
how much better things get.
And I'm optimistic that we won't have to muck up the API with any
non-floating-point interfaces to cairo.
Of course, any help on the above would be appreciated. I can dig up
pointers to the various in-progress patches if anyone would like to
jump in here. Just let me know.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20061005/7bb0f4d4/attachment.pgp
More information about the cairo