Re: [Librsvg-devel] Porting librsvg to an Embedded Platform

[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
far:

* 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
  grid.

* 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
units.

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.

-Carl

_______________________________________________
cairo mailing list
[email protected]
http://cairographics.org/cgi-bin/mailman/listinfo/cairo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBFJS0y6JDdNq8qSWgRAgT0AJ9c+UkVP6qS42SlzGPKuXaWdbq3KwCeIaNH
ECo5EHqo39bs+FlmfHx3N+E=
=OV+D
-----END PGP SIGNATURE-----