Re: penalty for double buffering

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.

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]