Re: penalty for double buffering
- From: Soeren Sandmann <sandmann daimi au dk>
- To: Steven Jenkins <steven jenkins ieee org>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: penalty for double buffering
- Date: 13 Dec 2003 22:10:37 +0100
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.
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.
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.
- There is simply overhead associated with creating the extra
pixmap and the extra GC's necessary. It shouldn't be a
factor 4 though.
] [Thread Prev