[cairo] Patches for speeding up _cairo_fixed_from_double

[Daniel Amelang]

On 11/6/06, Behdad Esfahbod <behdad at behdad.org> wrote:
> On Mon, 2006-11-06 at 16:51 -0500, Carl Worth wrote:
> > On Mon, 6 Nov 2006 13:26:51 -0800, "Daniel Amelang" wrote:
> > > > ...I'm going to be putting together a development snapshot
> > > > with all the performance work that's been happening since the
> > > > 1.2 branch...
> > >
> > > You might want to hold off on that development snapshot for a just
> > > little longer. I have two more performance-related patches in the oven
> > > that could potentially make a number of people happy.
> >
> > As a rule, we're going to try to break our bad habit of delaying
> > development snapshots to try to get the next great feature in. I think
> > we'll be a lot better off if we can release a new snapshot every week
> > and each one faster than the one from the week before.
>
> Yeah, I also want to emphasize that this is a lot more important about
> the first developmental release in a cycle, as the longer we delay 1.3.x
> the harder it will be to track down regressions between 1.3.x and the
> latest stable release, ie. 1.2.6 at the moment.  When we have the first
> devel release out, it's all linear from there on.
>
>
> > > Second, I have an optimization that's similar to this
> > > _cairo_fixed_from_double one that addresses some of the slowness in
> > > rendering glyphs, especially in the case that was profiled here:
> > >
> > > http://www.o-hand.com/~jorn/pango-benchmarks/210-softfloat/
> > >
> > > This optimization, plus a small patch for pango (also in the works),
> > > should improve text rendering on both ARM and x86.
>
> So, what is the required change in pango?
> Again, too bad PangoMatrix and cairo_matrix_t are not compatible.  We
> could use the optimized cairo matrix operations if they were.

The required change is to replace PANGO_UNITS in pangocairo-fc-font.c
with an inline function almost identical to the new
_cairo_fixed_from_double function. This significantly speeds up
compute_glyph_extents, which accounts for all the __muldf3 found here
(third function down):

http://folks.o-hand.com/jorn/pango-benchmarks/210-softfloat/pango-cairo.txt

Notice that the profile doesn't attribute the muldf3 calls to
compute_glyph_extents, but I'm 99% sure that it should, as the
functions listed don't perform any floating point multiplies, and they
all are ancestors to compute_glyph_extents, so I think it's a case of
what is described here:

http://oprofile.sourceforge.net/doc/interpreting-callgraph.html

Dan