[cairo] Patches for speeding up _cairo_fixed_from_double

[Owen Taylor]

On Wed, 2006-11-08 at 21:03 -0600, Sean Kelley wrote:
> On 11/2/06, Daniel Amelang <daniel.amelang at gmail.com> wrote:
> > Attached are patches resulting from the discussion here:
> >
> > http://lists.freedesktop.org/archives/cairo/2006-October/008285.html
> 
> 
> Xan ran this patch in comparison here.
> 
> http://blogs.gnome.org/view/xan/2006/11/06/0
> 
> It is an improvement, but I am still liking Matt Hoosier's pangoxft
> patch to 2.10.

It was an interesting experiment to do once for measurement 
purposes, but reverting back to Xft for text rendering is a really bad
idea; among other things:

 - There are a lot of potential big optimizations that are impossible
   once you have two separate libraries driving RENDER
 
 - Xft simply can't do everything that cairo can do for drawing
   text.

 - Xft is unmaintained

If the floating point arithmetic and conversions for text rendering are
a serious problem and can't be sufficiently optimized the answer
isn't "oh, let's use a different library for drawing graphics
that happen to be text". The approach that makes sense to me is to
instead have an integer or fixed point API that callers can optionally
use.

The look of the API would be pretty obvious, though except for the
choice of the fixed point format:

typedef struct {
  unsigned long        index;
  int                  x; // 24.8 ?
  int                  y;
} cairo_glyph_fixed_t;

void
cairo_show_glyphs_fixed_point (cairo_t *cr, 
                               const cairo_glyph_fixed_t *glyphs, 
                               int num_glyphs);

But, you say, then you'd have to add fixed point matrices, 
transforms, etc, all the way through cairo. 

My recommendation is something else ... a simple and very fast code 
path for the case that the CTM is an integer translation, and for
everything else, just convert the fixed point back to doubles; if
you try to use the fixed point API when it's not useful, it still
works, but you lose a little bit of performance rather than gaining
a lot of performance.

(Pango could have two code paths at the lowest level of text rendering -
one used for integer translations, one used for everything else. 
The harm in always using the fixed point API is that translation
from 22.10 to 24.8 to double loses precision compared to going 
directly from 22.10 to double.)

Glyph measurement may also be an issue, but since there's a 
(fixed-point) cache in Pango ahead of cairo, it's going to be
pretty well hidden in both benchmarks and most real use cases. But
if measurement indicated that it was worthwhile, it's certainly
amenable to the same sort of technique.

Regards,
					Owen