[cairo] Patches for speeding up _cairo_fixed_from_double

[Sean Kelley]

Hello Owen,

On 11/9/06, Owen Taylor <otaylor at redhat.com> wrote:
> 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

I agree.  Our focus is embedded usage and anything involving those
patches is entirely short term to meet our immediate needs.

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

This is of course an ideal approach.  We have discussed this at Guadec
and the Gnome Summit in our Gnome Mobile And Embedded group (GMAE).


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

True, quite a bit of work there.

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

I think that definitely has merit.

Sean


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