Pango Performance (was: Re: --gtk-unbuffered)

[Hans Breuer <hans breuer org>]

At 15:20 25.02.01 -0500, Owen Taylor wrote:
>Hans Breuer <hans breuer org> writes:
>> testgtk::file selection : (takes some seconds to show up in the gtk build
>> 	directory)
>> 	requires further investigation. My current guess is, that the
>> 	whole file lists gets caculated (and rendered?) before showing
>> 	the dialog.
>
>No, that's not it. And it is, again, not noticeably slow on
>Unix.

Simply interrupting the file dialog while it was initializing led to the
following call stack:

pango_layout_check_lines
pango_layout_get_extents_internal
pango_layout_get_extents
pango_layout_get_pixel_extents
cell_size_request
set_cell_contents
real_insert_row
gtk_clist_append		<-- gets called for every file name
gtk_file_selection_init

It arises the question, why it is necessary to calculate the height of
every filename (ok, it isn't rendered, but "pre-rendered" :-), instead of
simply calculating the total height of the clist with the maximum height
from the used font. Which would give equally spaced lines as another
benefit ...

BTW: here's the patch to get the factor five slowness decreasing. I've seen
much faster rendering than previously reported on my 400 MHz Pentium, NT4,
VC60 (almost the same as reported by Owen on X), but this needs further
investigation (too much parameters changed at once). Maybe I simply need to
buy a new notebook to get acceptable Pango performance :)

BTW2: thanks Alex for pointing me at the right direction.

Tor: the patch below appears to make the font data persistence not needed
anymore. Maybe we should get rid of it again? (The
<?>/etc/pango/cache.win32/*.C looks too much unix-ish to be anyway )

Thanks,
	Hans

diff --exclude-from=c:\util\tool\diff.ign -u -r
from-cvs/pango/pango/pangowin32.c my-gtk/pango/pango/pangowin32.c
--- from-cvs/pango/pango/pangowin32.c	Fri Feb 16 17:20:28 2001
+++ my-gtk/pango/pango/pangowin32.c	Wed Feb 28 22:31:42 2001
@@ -70,6 +70,7 @@
   int buf_size;
   HFONT oldfont;
   HBITMAP oldbm;
+  gchar *glyphs_avail; /* cache info if a glyph is available */
 };
 
 struct _PangoWin32MetricsInfo
@@ -863,6 +864,7 @@
   info->logfont = *lfp;
   info->hfont = NULL;
   info->buf_hbm = NULL;
+  info->glyphs_avail = g_new0 (gchar, 16384);
 
   win32font->n_subfonts++;
   
@@ -1002,6 +1004,7 @@
 #ifdef HEAVY_DEBUGGING
   static int dispx = 5, dispy = 0;
 #endif
+  gint has_glyph = 0; /* 1=yes, 2=no */
 
   subrange = pango_win32_unicode_classify (wc);
   if (PANGO_WIN32_U_LAST_PLUS_ONE == subrange)
@@ -1011,6 +1014,16 @@
 					 subrange))
     return FALSE;
 
+  /*
+   * This is the main performance bottleneck, so lets
+   * cache the info once got ...
+   */
+  has_glyph = (info->glyphs_avail[wc / 4] >> ((wc % 4) * 2)) & 0x03;
+  if (1 == has_glyph)
+    return TRUE;
+  else if (2 == has_glyph)
+    return FALSE;
+
   if (info->buf_hbm == NULL)
     {
       info->buf_hdc = CreateCompatibleDC (pango_win32_hdc);
@@ -1086,7 +1099,11 @@
     }
 #endif
 
-  return (memcmp (info->buf, info->default_char_buf, info->buf_size) != 0);
+  has_glyph = (0 != memcmp (info->buf, info->default_char_buf,
info->buf_size) ? 1 : 2);
+
+  info->glyphs_avail[wc / 4] |= (has_glyph << ((wc % 4) * 2));
+
+  return (1 == has_glyph);
 }
 
 /**
@@ -1197,6 +1214,7 @@
 	  DeleteObject (info->default_char_hbm);
 	  DeleteDC (info->buf_hdc);
 	}
+      g_free (info->glyphs_avail);
       g_free (info);
     }
 
 
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert