[gtk+] gtk-demo: Fix images demo



commit 8ccdd5b7cfd306e08b522d48ec1a4cd880b793c3
Author: Matthias Clasen <mclasen redhat com>
Date:   Sat Apr 12 20:39:26 2014 -0700

    gtk-demo: Fix images demo
    
    The incremental loading was broken by GtkIconHelper - queuing a
    redraw is no longer sufficient to cause GtkImage to redraw with
    the new pixbuf contents.
    Pointed out by Jasper St. Pierre.

 demos/gtk-demo/images.c |   15 +++++++++------
 1 files changed, 9 insertions(+), 6 deletions(-)
---
diff --git a/demos/gtk-demo/images.c b/demos/gtk-demo/images.c
index baa2d49..a36c8df 100644
--- a/demos/gtk-demo/images.c
+++ b/demos/gtk-demo/images.c
@@ -50,18 +50,21 @@ progressive_updated_callback (GdkPixbufLoader *loader,
                               gpointer     data)
 {
   GtkWidget *image;
+  GdkPixbuf *pixbuf;
 
   image = GTK_WIDGET (data);
 
   /* We know the pixbuf inside the GtkImage has changed, but the image
-   * itself doesn't know this; so queue a redraw.  If we wanted to be
-   * really efficient, we could use a drawing area or something
-   * instead of a GtkImage, so we could control the exact position of
-   * the pixbuf on the display, then we could queue a draw for only
-   * the updated area of the image.
+   * itself doesn't know this; so give it a hint by setting the pixbuf
+   * again. Queuing a redraw used to be sufficient, but nowadays GtkImage
+   * uses GtkIconHelper which caches the pixbuf state and will just redraw
+   * from the cache.
    */
 
-  gtk_widget_queue_draw (image);
+  pixbuf = gtk_image_get_pixbuf (GTK_IMAGE (image));
+  g_object_ref (pixbuf);
+  gtk_image_set_from_pixbuf (GTK_IMAGE (image), pixbuf);
+  g_object_unref (pixbuf);
 }
 
 static gint


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