Re: penalty for double buffering

[Steven Jenkins <steven jenkins ieee org>]

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 
http://prdownloads.sourceforge.net/tidal/tidal-3.11.2-rc2.tar.gz?download

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.
>
>
> Some possibilities:
>
>         - 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.

Steve