Re: Pango Performance (was: Re: --gtk-unbuffered)
- From: Tor Lillqvist <tml Iki fi>
- To: Hans Breuer <hans breuer org>
- Cc: gtk-devel-list gnome org
- Subject: Re: Pango Performance (was: Re: --gtk-unbuffered)
- Date: Thu, 1 Mar 2001 17:15:02 +0200 (FLE Standard Time)
Hans Breuer writes:
> Tor: the patch below appears to make the font data persistence not needed
> anymore. Maybe we should get rid of it again?
Umm, I would have preferred a fix that would have made pango-win32
make better use of the cached coverage that it tries (but fails?) to
use. I think it would be a good idea to also use the cached glyph
extents in a hash table approach that pangoft2.c uses, as Alex
But if you have at the code more closely and lately, and think this is
a better approach, it's fine with me.
> + info->glyphs_avail = g_new0 (gchar, 16384);
I would prefer 65536/4 here, just to make it more clear what this
magic number is related to.
> + if (1 == has_glyph)
> + else if (2 == has_glyph)
> + return (1 == has_glyph);
It would be preferrable if all of Pango used the same coding style
conventions. While I certainly understand the rationale for this style
of writing equality tests, it is nonetheless not used in any of the
other code, which can be confusing. Or what do others think?
] [Thread Prev