On Tue, 24 Apr 2007 00:19:08 +0100, Damon Chaplin wrote: > On Mon, 2007-04-23 at 20:09 +0100, Emmanuele Bassi wrote: > > floats. in Clutter, for instance, most of the operations are done using > > fixed point algebra and transforming doubles in the public API into > > 16.16 or 21.11 fixed point numbers internally; That's a similar approach as has been used in cairo very successfully. > > we also expose a fixed > > point API to avoid using doubles altogether. is this hard? yes. As a datapoint, cairo does not do this. > > cairo and pango developers and contributors went all the lengths to > > reduce the floating point usage in their libraries; we shouldn't screw > > the developers on embedded devices *again*. > > But the cairo API already uses doubles, for coordinates and > transformations. So if the canvas used fixed point numbers you'd be > converting to doubles and then back again. Some people have misunderstood what kinds of optimizations happened in cairo. Cairo has always had a floating-point API, with an implementation that tries to get to fixed-point as quickly as possible. There were several performance problems that were fixed between the 1.2 and 1.4 releases of cairo that involved the following: * Using clever techniques to make the conversion of floating-point to fixed-point values as fast as possible. * Using similar techniques to make the rounding of floating-point values to integers as fast as possible. * Avoiding floating-point arithmetic where the result was unchanged, (multiplying by an identity matrix, for example). At this point, cairo seems plenty fast on embedded systems for the kinds of things that people are throwing at it. Now, some of that speed comes from simply not doing some of the scaling and transformation that might be desired, (see the identity transformation optimization mentioned above). But even if more scaling and rotation were desired, there would be plenty of ways to optimize this, (using fixed-point arithmetic when the scaling is small enough to avoid overflow, using fast integer techniques for computing things like square roots, etc.). And all of that could be done without ever adding any fixed-point API to cairo. I'm quite convinced that using floating-point at the interface, and fixed-point internally as needed provides the right combination of performance and ease-of-use for cairo. I'd highly recommend any new canvas interfaces being proposed follow the same approach. -Carl
Attachment:
pgpHMupB3xzLg.pgp
Description: PGP signature