Re: penalty for double buffering
- From: Steven Jenkins <steven jenkins ieee org>
- To: gtk-app-devel-list gnome org
- Subject: Re: penalty for double buffering
- Date: Sat, 13 Dec 2003 14:41:30 -0800
Soeren Sandmann wrote:
Steven Jenkins <steven jenkins ieee org> writes:
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.
I would be interested in seeing your application.
Thanks for the quick reply. The source is available at
The file in question is drivers/viewport.c. If you want to actually run
the test case, I'll send you the input data for it.
This file is a straightforward port of an old Borland C MS-DOS graphics
driver. It was my first (and only) GTK+ app, and I made it largely by
parroting code from Havoc Pennington's book. It's for data display only,
not a conventional GTK+ app. For example, there's no gtk_main()--the
outer data acqusition loop calls gtk_main_iteration(). But it works well.
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.
- Your video card doesn't have enough memory. This can cause
the pixmaps to end up in system memory instead of video
memory, causing drawing to not be accelerated.
Doesn't seem likely. The test case display is only 800x600, and the
video card is a relatively recent GeForce4 MX 440 with 64 MB of RAM.
Worse, if the source pixmap ends up in video memory, and the
temporary double-buffer pixmap doesn't, the data will be
read across the bus from the video memory, which is slow.
Can this happen for reasons other than insufficient video memory? A
configuration problem of some kind?
- There is simply overhead associated with creating the extra
pixmap and the extra GC's necessary. It shouldn't be a
factor 4 though.
I expect some penalty, just not this much.
] [Thread Prev