[cairo] Cairo vs. Xft glyph rendering

Xan Lopez xan.lopez at gmail.com
Mon Dec 11 04:53:49 PST 2006


Hey!

On 12/11/06, Behdad Esfahbod <behdad at behdad.org> wrote:
> This is basically what I've done now, and pushed into my tree under the
> branch xlib-show-glyphs-fast:
>
> http://gitweb.freedesktop.org/?p=users/behdad/cairo.git;a=shortlog;h=xlib-show-glyphs-fast
>
> The patch set is attached.  I started by introducing a new type
> cairo_glyph_fixed_t and pass that down, but at the end I figured this is
> actually a penalty for most backends and not much gain for any, so I
> backed that up.
>
> Other than compressing glyphs into elements, I also made a semantic
> change to show_glyphs() calls all over the tree, that is, those
> functions that get a non-const cairo_glyph_t* are allowed to modify the
> glyph array unless then return CAIRO_STATUS_UNSUPPORTED.  This means,
> backends can modify the input glyph array or use it for totally
> different things instead of having to duplicate it or allocate memory.
> My rewritten cairo_xlib_show_glyphs() heavily uses this.
>

Superb job, thanks a lot!

> Anyway, patchset attached.  It looks ready to me, and on my laptop saves
> some 6% on timetext (plus a malloc per show_glyphs()).
>
> Waiting for numbers :-)

Numbers, numbers :)

* Average of 5 timetext runs:

Cairo 1.3.6, Pango HEAD, GTK+ 2.10.6:
Drawn label 2813 times. Average time spent drawing (in seconds): 0.001636

Cairo 1.3.6+cairo_xlib_show_glyphs love, Pango HEAD, GTK+ 2.10.6:
Drawn label 3013 times. Average time spent drawing (in seconds): 0.001513

Expose time improvement: ~8%
Total performance improvement:  ~7%

Amazing, we have reached 3000 labels/minute in my ARM hardware. We are
rushing into the GTK+ 2.6 raw performance numbers, which are at ~3200
labels/minute. We now draw roughly 900 labels/minute more than one
month ago, and our expose time has decreased from ~0.0024 to ~0.0015
seconds.

Now, one question. How is it possible that our labels/minute numbers
are almost equal to GTK+ 2.6/Xft but our expose time is still almost
double (0.0015 vs 0.0008)? Is it some inherent defect in timetext?
Other improvements in glib/gtk+ from 2.6 to 2.10 could explain it?

Anyway, I'll do some torturing and xtracing now :)

Cheers, Xan

>
>
> --
> behdad
> http://behdad.org/
>
> "Those who would give up Essential Liberty to purchase a little
>  Temporary Safety, deserve neither Liberty nor Safety."
>         -- Benjamin Franklin, 1759
>
>
>
>
>


More information about the cairo mailing list