Re: Cairo based engine api for GTK+ 3.0



On Thu, 2009-06-18 at 09:42 +0100, Thomas Wood wrote:
> During the themeing hackfest, I started work porting the engine API to
> cairo. The first step was to convert the default engine to cairo, of
> which I've published a branch here:

Thanks for doing this! Having more of gtk switched over to using cairo,
makes it far more interesting when looking for ways to improve cairo's
performance over the whole desktop. And coupled with the excellent work
on client-side windows and decorations, I hope it not only allows us to
make GTK+ more aesthetically pleasing but easier to maintain and port as
well.

I did find one issue in:
commit b29fc9bb340fc5af8aadf15eb12e16294cdb0ad2
Author: Thomas Wood <thos gnome org>
Date:   Wed Feb 18 18:52:45 2009 +0000

    [gtkstyle] convert the default implementation of draw layout to cairo
    
    Note that this no longer stipples the background of insensitive text
    if a background colour has been set.

...
@@ -5283,30 +5153,34 @@ gtk_default_draw_layout (GtkStyle        *style,
                          gint             y,
                          PangoLayout     *layout)
 {
-  GdkGC *gc;
+  cairo_t *cr;
+  GdkColor *gc;
+
+  cr = gdk_cairo_create (window);
 
-  gc = use_text ? style->text_gc[state_type] : style->fg_gc[state_type];
-  
   if (area)
-    gdk_gc_set_clip_rectangle (gc, area);
+    {
+      gdk_cairo_rectangle (cr, area);
+      cairo_clip (cr);
+    }
 
   if (state_type == GTK_STATE_INSENSITIVE)
     {
-      PangoLayout *ins;
+      gdk_cairo_set_source_color (cr, &style->white);
+      cairo_move_to (cr, x + 1, y + 1);
+      pango_cairo_layout_path (cr, layout);
+      cairo_fill (cr);
+    }

The use of pango_cairo_layout_path(); cairo_fill(); is a performance
nightmare, use pango_cairo_show_layout() instead. [The difference
between the two is that pango_cairo_layout_path() will extract the paths
from the glyphs and fill by sending very long lists of trapezoids to the
X server every time, whereas pango_cairo_show_layout() will cache the
glyphs masks on the X server (as pixmaps) and just issue a short list of
indices to composite. So the latter is far more computationally, memory
and bandwidth efficient.]
-ickle



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]