new patch to fix issue with canvas redraw behaviour when canvas items are "slow" to update (e.g. a canvas line with 1150 points)

git-svn-id: svn://localhost/ardour2/branches/2.0-ongoing@13531 d708f5d6-7413-0410-9779-e7cbd77b26cf

1 files changed, 46 insertions, 0 deletions

diff --git a/tools/current-gtk-patches/gnome-canvas-slow-idle.patch b/tools/current-gtk-patches/gnome-canvas-slow-idle.patch
new file mode 100644
index 0000000000..d8c737c023
--- /dev/null
+++ b/tools/current-gtk-patches/gnome-canvas-slow-idle.patch
@@ -0,0 +1,46 @@
+--- gnome-canvas.c	2011-01-31 07:19:30.000000000 -0500
++++ ../../../libgnomecanvas-2.30.3/libgnomecanvas/gnome-canvas.c	2012-11-19 13:10:20.552383069 -0500
+@@ -75,6 +75,7 @@
+ 
+ #include <config.h>
+ 
++#include <sys/time.h>
+ #include <math.h>
+ #include <string.h>
+ #include <stdio.h>
+@@ -3202,16 +3203,34 @@
+ idle_handler (gpointer data)
+ {
+ 	GnomeCanvas *canvas;
++	struct timeval enter, leave, diff;
+ 
+ 	GDK_THREADS_ENTER ();
+ 
+ 	canvas = GNOME_CANVAS (data);
+ 
++	gettimeofday (&enter, NULL);
+ 	do_update (canvas);
++	gettimeofday (&leave, NULL);
+ 
+-	/* Reset idle id */
++	/* Reset idle id*/
+ 	canvas->idle_id = 0;
+ 
++	timersub (&leave, &enter, &diff);
++
++	/* GnomeCanvas can be REALLY REALLY slow at updating/recomputing
++	 * lines. During motion handling this can lead to situations where the
++	 * next motion event arrives before the update is complete, and
++	 * as a result, GTK never gets to run the redraw/expose cycle.
++	 *
++	 * This cannot be fixed until we replace the canvas, so for 
++	 * force an actual redraw 
++	 */
++	
++	if (diff.tv_sec > 0 || diff.tv_usec > 30000) {
++		gdk_window_process_updates (canvas->layout.bin_window, 1);
++	}
++
+ 	GDK_THREADS_LEAVE ();
+ 
+ 	return FALSE;