Re: Floating point in pango

[Matthew Allum <mallum openedhand com>]

Hi;

On Thu, 2006-07-20 at 11:41 -0700, Carl Worth wrote:
> 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.
> 

Yes and I fully appreciate this. But this also confuses me to why then
only offer a float API! Especially in something like Cairo where its not
unlikely for its library calls to be made heavily - animations for
example or measuring per glyph extents in a string. 

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

Just so Im clear, all Im suggesting is fixed point variants of existing
API funcs that take the same arguments just in a different type - fixed
rather than float. The original 'sibling' calls still exist. The
variants would be named as such to be clearly fixed versions. Id hope
this, clear documentation ( of which Cairo already has ) and the lack of
any fixed library ( which I agree is out of scope ) would address the
above issues to some degree 

Remember OpenGL has this kind of API, where there are variants of the
same function call but taking different types of args. Its
implementation is less clear than Im suggesting and I, at least, have
never heard anyone say this is a serious downside of the GL API. 

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

Ok. 

> > 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?
> 

Yes - basically just increase the use/efficiency of fixed internally in
pango-cairo and cairo but at least for now connect the two via floats ?
Then see what that gets us ? Focusing on the font stuff  ? 

Many thanks;

  -- Matthew