Re: Roundtrip in gdk_flush()

[Owen Taylor <otaylor redhat com>]

Soeren Sandmann <sandmann daimi au dk> writes:

> Owen Taylor <otaylor redhat com> writes:
> 
> > I think except on SMP machines, the 25% in gdk_flush() doesn't
> > indicate any real problems... we are just waiting for the X server to
> > catch up.  (Even in SMP cases, I don't think there is any point in
> > getting ahead of the X server; we'd just end up blocking with full
> > request queues a little later anyways.)
> 
> Well, I did some tests:
> 
> I instrumented gtk with this patch to gtkcontainer.c:
> 
> alpine:~/vertigo/gtk+/gtk% cvs diff -u gtkcontainer.c
> Index: gtkcontainer.c
> ===================================================================
> RCS file: /cvs/gnome/gtk+/gtk/gtkcontainer.c,v
> retrieving revision 1.107
> diff -u -r1.107 gtkcontainer.c
> --- gtkcontainer.c	20 Mar 2002 21:47:00 -0000	1.107
> +++ gtkcontainer.c	25 Mar 2002 19:24:40 -0000
> @@ -976,6 +976,10 @@
>    return GTK_IS_RESIZE_CONTAINER (widget) ? (GtkContainer*) widget : NULL;
>  }
>  
> +static GTimer *timer = NULL;
> +static gdouble total = 0.0;
> +static guint n_resizes = 0;
> +	     
>  static gboolean
>  gtk_container_idle_sizer (gpointer data)
>  {
> @@ -1003,6 +1007,9 @@
>  
>    gdk_window_process_all_updates ();
>  
> +  total += g_timer_elapsed (timer, NULL);
> +  g_print ("time to resize: %f\n", total / ++n_resizes);
> +
>    GDK_THREADS_LEAVE ();
>  
>    return FALSE;
> @@ -1041,9 +1048,16 @@
>  		{
>  		  GTK_PRIVATE_SET_FLAG (resize_container, GTK_RESIZE_PENDING);
>  		  if (container_resize_queue == NULL)
> -		    gtk_idle_add_priority (GTK_PRIORITY_RESIZE,
> +		    {
> +		      if (!timer)
> +			timer = g_timer_new ();
> +		      
> +		      g_timer_reset (timer);
> +		      
> +		      gtk_idle_add_priority (GTK_PRIORITY_RESIZE,
>  					   gtk_container_idle_sizer,
>  					   NULL);
> +		    }
>  		  container_resize_queue = g_slist_prepend (container_resize_queue, resize_container);
>  		}
>  	      break;
> 
> and then I tried opaque resizing the notebook test in testgtk.c with
> various implementations of gdk_flush():
> 
> 
> (a) Unmodified gtk+ with gdk_flush() == XSync ():             0.019730
> (b) gtk with gdk_flush() == XFlush():                         0.005460

I'm not sure there is a point in doing this one; if you make gdk_flush() == XFlush()
you are introducing utter incorrectness.

> (c) with gdk_window_process_all_updates() calling XFlush()    0.005903
> (d) calling gdk_flush() == XSync in idle handler              0.005445
> 
> 
> So it seems that getting rid of the round trip does have a significant
> impact on the time to respond to events. 

It's not clear to me that what you are measuring here really corresponds to 
a user visible idea of performance... clearly process_all_updates() is going
to finish sooner if you don't wait for X drawing to finish before going on,
but that doesn't mean that the user sees things drawn more quickly.

(And I can't really think of why they _would_ be drawn more quickly for
a uniprocessor system.)

Maybe a better metric would be frame rate -- how many times gdk_window_process_all_updates() 
is called per second. 

Regards,
                                        Owen