penalty for double buffering

[Steven Jenkins <steven jenkins ieee org>]

I have an application that emulates strip chart recorders using GDK 
calls to plot on a pixmap. It uses gdk_draw_pixmap() to copy rectangles 
from the pixmap back onto itself, creating the impression of sliding to 
the left the way the paper does on a real recorder.
I originally wrote it for GTK+1.2, and I was pleased at how fast it ran 
without a great effort to minimize the area passed to gtk_widget_draw(). 
Updating several channels at 50 Hz was not a problem, even on older 
hardware.
When I ported the application to GTK+2, I replaced the gtk_widget_draw() 
call with gdk_window_invalidate() (as the porting guide recommends), and 
it works. There's quite a performance hit, however. I have a test case, 
almost completely dominated by graphics calls. The GTK+1.2 version runs 
in 2.4 seconds, while the GTK+2 version requires 6.9 s.
Based on an earlier suggestion on this list, I disabled double buffering 
with gtk_widget_set_double_buffered(drawing_area, FALSE). That reduced 
the runtime dramatically, to 1.4 s.
It's fast enough with double buffering on, but I'm having a hard time 
understanding, on purely theoretical grounds, how adding another memory 
transfer can cause a factor of 4 degradation in performance. It's 
already doing one such transfer (at least). It seems like the worst case 
penalty would be a factor of 2.
This is Gentoo Linux, kernel 2.4.20, GTK+ 2.2.4, X Windows.

Any insights?

Steve