rendering cleanup

I’ve spent the last 2 weeks in a GTK branch purging the old X drawing code from GDK to see if it would work. Not only did it work, but it made quite a few people happy to see this done. So this will probably be merged into GTK master rather soon, along with lots of deprecations for GTK 2.22. The patchset removes roughly 150 API calls from the GTK code. If you have an application or library that doesn’t use Cairo yet but still uses the old drawing calls, you will have to port it to Cairo to be GTK compatible. What follows is a rough draft of what I intend to become a porting guide for the GTK documentation.

What code was removed?

The cleanup basically just removes two objects from GDK: GdkGC and GdkImage. All the functions using them, most prominently the gdk_draw_ set of functions like gdk_draw_rectangle() and gdk_draw_drawable() were of course removed, too. As GdkGC is roughly equivalent to cairo_t and GdkImage was used for drawing images to GdkDrawables, which Cairo supports automatically, a transition is usually straightforward and does not require refactoring.

Why was this cleanup done?

  • Bad semantics
    In the X11 backend, a GdkGC is represented by a server-side object so creation and destruction are very expensive. This resulted in GTK creating these objects in advance and requiring code to use a “setup, use, restore” approach, which required the extra cleanup work and was error-prone. Also, a lot of operations provided by GdkGC were hard to understand and quirky. This posed a lot of issues when trying to port GTK to other platforms like Microsoft Windows, Apple’s Quartz rendering engine or OpenGL.

  • Outdated featureset
    The GDK drawing API mapped very closely to the core X drawing API which was invented 20 years ago while the Cairo API is modeled after the modern PDF rendering model, which supports bezier curves, antialiasing, translucent drawables, antialiased clipping and masking and resolution independence, all of which are not available in the GDK API.

  • Bad API
    A lot of functions in GDK that took a GdkGC as an argument used only some of the GC’s properties but not all of them. Unfortunately it was rarely clear what operations were supported and which weren’t.

  • Performance
    A lot of work is spent on making Cairo accelerated better on GPUs, while such work is not done for the old GdkGC code. In a lot of cases trying to this was not even possible or very complex due to the mentioned quirkiness of the old drawing operations.

When and how should you port your code?

Porting your code should happen as soon as possible. The replacement APIs have been available since Gtk 2.8, so it is not necessary to depend on recent code.
When porting your code, you want to replace GdkImage uses with a Cairo image surface and draw to/from it using the usual Cairo APIs. Whenever your code uses a GdkGC, you want to replace it by creating a cairo_t instead and replace each function call with the equivalent Cairo calls. See the outdated function’s Gtk 2 documentation for the replacements.

A few examples

This section contains examples for a few common idioms used by applications that have been ported to use Cairo and how the code was replaced.

  • Drawing a GdkPixbuf onto a GdkDrawable
    Drawing a pixbuf onto a drawable used to be done like this:

    gdk_draw_pixbuf (window,
                     gtk_widget_get_style (widget)->black_gc,
                     0, 0
                     x, y,
                     gdk_pixbuf_get_width (pixbuf),
                     gdk_pixbuf_get_height (pixbuf),
                     0, 0);

    Doing the same thing with Cairo:

    cairo_t *cr = gdk_cairo_create (window);
    gdk_cairo_set_source_pixbuf (cr, pixbuf, x, y);
    cairo_paint (cr);
    cairo_destroy (cr);

    Note that very similar code can be used for drawing pixmaps by using gdk_cairo_set_source_pixmap() instead of gdk_cairo_set_source_pixbuf().

  • Drawing a tiled GdkPixmap to a GdkDrawable
    Tiled pixmaps are often used for drawing backgrounds. Old code looked something like this:

    GdkGCValues gc_values;
    GdkGC *gc;
    /* setup */
    gc = gtk_widget_get_style (widget)->black_gc;
    gdk_gc_set_tile (gc, pixmap);
    gdk_gc_set_fill (gc, GDK_TILED);
    gdk_gc_set_ts_origin (gc, x_origin, y_origin);
    /* use */
    gdk_draw_rectangle (drawable, gc, TRUE, 0, 0, width, height);
    /* restore */
    gdk_gc_set_tile (gc, NULL);
    gdk_gc_set_fill (gc, GDK_SOLID);
    gdk_gc_set_ts_origin (gc, 0, 0);

    The equivalent Cairo code looks like this:

    cairo_t *cr;
    cr = gdk_cairo_create (drawable);
    gdk_cairo_set_source_pixmap (cr, pixmap, x_origin, y_origin);
    cairo_pattern_set_extend (cairo_get_source (cr), CAIRO_EXTEND_REPEAT);
    cairo_rectangle (cr, 0, 0, width, height);
    cairo_fill (cr);
    cairo_destroy (cr);

    Again, you can exchange pixbufs and pixmaps by using gdk_cairo_set_source_pixbuf() instead of gdk_cairo_set_source_pixmap().

  • Drawing a PangoLayout to a clipped area
    Drawing layouts clipped is often used to avoid overdraw or to allow drawing selections. Code would have looked like this:

    GdkGC *gc;
    /* setup */
    gc = gtk_widget_get_style (widget)->text_gc[state];
    gdk_gc_set_clip_rectangle (gc, &area);
    /* use */
    gdk_draw_layout (drawable, gc, x, y, layout);
    /* restore */
    gdk_gc_set_clip_rectangle (gc, NULL);

    With Cairo, the same effect can be achieved using:

    cairo_t *cr;
    cr = gdk_cairo_create (drawable);
    /* clip */
    gdk_cairo_rectangle (cr, &area);
    cairo_clip (cr);
    /* set the correct source color */
    gdk_cairo_set_source_color (cr, >k_widget_get_style (widget)->text[state]);
    /* draw the text */
    cairo_move_to (cr, x, y);
    pango_cairo_show_layout (cr, layout);
    cairo_destroy (cr);

    Clipping using cairo_clip() is of course not restricted to text rendering and can be used everywhere where GC clips were used. And using gdk_cairo_set_source_color() with style colors should be used in all the places where a style’s GC was used to achieve a particular color.

    What should you be aware of?

  • No more stippling
    Stippling is the usage of a bi-level mask, called a GdkBitmap. It was often used to achieve a checkerboard effect. You can use cairo_mask() to achieve this effect. To get a checkerbox mask, you can use code like this:

    static cairo_pattern_t *
    gtk_color_button_get_checkered (void)
        /* need to respect pixman's stride being a multiple of 4 */
        static unsigned char data[8] = { 0xFF, 0x00, 0x00, 0x00,
                                         0x00, 0xFF, 0x00, 0x00 };
        cairo_surface_t *surface;
        cairo_pattern_t *pattern;
        surface = cairo_image_surface_create_for_data (data,
                                                       2, 2,
        pattern = cairo_pattern_create_for_surface (surface);
        cairo_surface_destroy (surface);
        cairo_pattern_set_extend (pattern, CAIRO_EXTEND_REPEAT);
        cairo_pattern_set_filter (pattern, CAIRO_FILTER_NEAREST);
        return pattern;

    Note that all properties that made use of stippling have been removed from GTK APIs as the result of stippling is not used in practice as it looks very outdated. Most prominently, stippling is absent from text rendering, in particular GtkTextTag.

  • Using the the target drawable also as the source or mask
    gdk_draw_drawable() allowed using the same drawable as source and target. This
    was often used to achieve a scrolling effect. Cairo does not allow this yet.
    You can however use cairo_push_group() to get a different intermediate target
    that you can copy to. So you can replace this code:

    gdk_draw_drawable (pixmap,
                       area.x + dx, area.y + dy,
                       area.x, area.y,
                       area.width, area.height);

    By using this code:

    cairo_t *cr = gdk_cairo_create (pixmap);
    /* clipping restricts the intermediate surface's size, so it's a good idea
     * to use it. */
    gdk_cairo_rectangle (cr, &area);
    cairo_clip (cr);
    /* Now push a group to change the target */
    cairo_push_group (cr);
    gdk_cairo_set_source_pixmap (cr, pixmap, dx, dy);
    cairo_paint (cr);
    /* Now copy the intermediate target back */
    cairo_pop_group_to_source (cr);
    cairo_paint (cr);
    cairo_destroy (cr);

    Cairo developers plan to add self-copies in the future to allow exactly this effect, so you might want to keep up on Cairo development to be able to change your code.

  • Using pango_cairo_show_layout() instead of gdk_draw_layout_with_colors()
    GDK provided a way to ignore the color attributes of text and use a hardcoded text color with the gdk_draw_layout_with_colors() function. This is often used to draw text shadows or selections. Pango’s Cairo support does not yet provide this functionality. If you use Pango layouts that change colors, the easiest way to achieve a similar effect is using pango_cairo_layout_path() and cairo_fill() instead of gdk_draw_layout_with_colors(). Note that this results in a slightly uglier-looking text, as subpixel anti-aliasing is not supported.


#1 St├ęphane on 07.27.10 at 20:54

You’re my Hero!

#2 slaine on 07.27.10 at 22:07

Excellent post. We’ve got lots of custom Gtk applications that do some rendering via GdkDrawingArea. This will be an invaluable reference point.

#3 nona on 07.28.10 at 23:29

Does that mean no more XLib dependency? IIRC Cairo does XCB, right? Sounds great. Please rip out more stuff.

#4 Magnus on 07.29.10 at 03:34

These changes are for GTK 3 right? It would be sad if these changes broke GTK:s excellent track record of ABI backwards compatibilty.

#5 Benjamin Otte on 07.29.10 at 10:13

Magnus: You can do all the work using GTK2 to get your apps ready. But of course,removing the old APIs is happening in GTK3 only. We will definitely never break exisiting applications.

nona: Yes, it makes porting to XCB easier but not free. You still need to provide support for Input handling etc.

#6 Elliott on 07.30.10 at 01:46

In “Drawing a tiled GdkPixmap to a GdkDrawable”, the new version seems to use “drawable” for cairo functions. I assume that should really be “cr”?

#7 Benjamin Otte on 07.30.10 at 09:29

Fixed, thanks.

#8 James Morris on 08.17.10 at 07:57

I’m writing an experimental MIDI sequencer/arpeggiator and updating Cairo in near-real-time for this uses rather more CPU resources than I am comfortable with. GDK on the other hand, uses next to nothing.

#9 Benjamin Otte on 08.17.10 at 08:14

Usually, this means you’re doing something stupid with your Cairo code that you don’t do with your GDK code. Like drawing lines that aren’t properly pixel-aligned.

#10 James Morris on 08.17.10 at 08:32

I would not have thought that to be the problem as the coordinates I use are ints. I shall ask on gtk-app-devel about it. I’m using a 33ms timeout to call gtk_widget_queue_draw and drawing a set of rectangles. (The rectangles appear and disappear in time with a MIDI sequence).

#11 Eric on 08.19.10 at 11:48

Is GTK+ still uses GDK internally ?