On Sun, 16 Jul 2006 21:20:16 +0100, Matthew Allum wrote: > On Sat, 2006-07-15 at 18:14 -0700, Carl Worth wrote: > > Please spend some time checking Jorn's posts + profiles, hopefully they > clearly show the issue with floating point causing slowdown in the font > rendering case at least ( on ARM ). I don't doubt that floating-point arithmetic is causing a problem on ARM. As you know Matthew, I did do quite a lot of work on ARM a few years ago, so I'm quite familiar with how crippled it is as far as floating-point is concerned. That experience (in addition to desire for robustness) is one thing that led me to implement cairo by converting to fixed-point as soon as possible. > > But my general take on this is that we are not ready to put new API > > into cairo for "performance reasons only" since we haven't > > sufficiently tried to optimize the implementation of the existing API > > yet. > > What do you see as downsides in extending API like this ? Would it even > be that bigger addition ? The downsides are serious. Here are a few: * A huge number of new functions to learn or at least sift through when learning cairo. * The possibility of mismatching the fixed- and floating-point functions when using cairo (with no compiler warning). * The danger of premature optimization by users thinking they need to use the "fast" API. (The implementation of both should be basically the same within cairo. The big win here will be in code above cairo, and if it's not necessary, then using fixed-point will introduce a lot of pain to the user.) * The danger of implementing/exporting a fixed-point arithmetic library, which would be out of scope for cairo. > Id be interested your thoughts on optimising FP to perform when you dont > have an FPU. Maybe the amount of FP calls in pango-cairo could simply be > heavily reduced ? Sure. If switching from floating-point to fixed-point within pango-cairo is a win, then please do that. > If Cairo cares about performing well on embedded type hardware ( maybe > it doesn't? ), use of fixed point seems pretty much mandatory on lower > end hardware - For example OpenGL ES, Playstation and Nintendo Handheld > graphics API's all use it. It is important to me for cairo to perform well on embedded hardware, but I'm not yet ready to sacrifice ease-of-use in the API in an effort to get this performance, (particularly when we don't yet know if that sacrifice is necessary). Here's my recommendation: Imagine that we added a fixed-point API to cairo today. Then, do the work necessary in pango, (or other important layers), to take advantage of that API. Also, do the work within cairo to operate on fixed-point values wherever possible. Once that work is done, all that should be left is a pair of conversions fixed->floating->fixed right at the cairo API. And at that point, if the overhead from that conversion is a performance problem then I will be happy to add new API for this. (And obviously, cairo would be using a faster approach for conversion than what it's using now.) That plan should involve no extra work, but has the huge benefit of not sacrificing the design of the API until we've proven that that is necessary in order to get the performance we want. Does that make sense? -Carl
Attachment:
pgpr1HROCjnNS.pgp
Description: PGP signature