[cairo] Report for the pango patch and proper profiles

[Behdad Esfahbod]

On Fri, 2006-12-01 at 03:59 -0500, Behdad Esfahbod wrote:
[...]
> First, the string is 64 chars long.  And your 56,191 should really be
> 56,192.  And that is exactly 3 pango_font_get_glyph_extents() calls per
> character per expose, plus 2 initial ones:
> 
>   56,192 = 292 * 64 * 3 + 64 * 2.
> 
> The initial ones come from the shaper and PangoLayout, and whose results
> are cached in PangoLayout.
[...]
> and that brings us down to 2 get_glyph_extents() calls per glyph per
> expose.
[...]
> and now there's only 1 get_glyph_extents() calls per glyph per expose.
> That one is a bit harder to fix, unless one caches per-line or per-item
> extents.  There's actually a patch for this already:
> 
>  http://bugzilla.gnome.org/show_bug.cgi?id=135683
> 
> The problem is, PangoLayout has API that gives away pointer to internal
> structures, such that you can modify the glyph widths, and that is
> legitimate use.  For example Firefox+Pango uses that to justify lines.
> So I was under the impression that we cannot meaningfully cache much,
> until I figured, well: we can cache, until the user asks for that evil
> pointer!  So, unless we have handed out a pointer to internal stuff, we
> can cache.  And even when we have given the pointer away, we can cache
> as part of a single pango operation.  So, I'm going to look more into
> this, and come up with a sensible scheme that doesn't introduce
> regressions.  With that in place, it may make sense to revert some of my
> pango_glyph_string_get_width() uses above and use the cached values;
> maybe not.  Donno.

This is mostly done and in pango-1.15.0 now.  Yes, down to zero
pango_font_get_glyph_extents() calls per expose!

The way I did is to cache line extents, with a cache status that can be
NOT_CACHED, CACHED, or LEAKED.  When a line is leaked, it means that the
user has access to its internals and may modify it, so, no caching.
This was actually pretty easy to implement.   And I decided to do it on
a per-line level because it was easier.

Bug is here:

  http://bugzilla.gnome.org/show_bug.cgi?id=135683

and committed patch here:

  http://bugzilla.gnome.org/attachment.cgi?id=77695&action=view

The patch does a bit less than what I explained in the quoted message,
but is more than enough of an optimization.  The only case that it may
have regressed is that we always cache both ink and logical extents,
while many scenarios (rendering labels even maybe) never care about ink
extents.  But I expect that this doesn't make any measurable difference
at all even ignoring the gained speed-up.

In my testings, this didn't affect the timetext test much, but sped up
the benchmark in the bug a bit.  Still, it's a lot more cache friendly
to not call get_glyph_extentswhen rendering.

Enjoy!

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