Re: penalty for double buffering

[Soeren Sandmann <sandmann daimi au dk>]

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.

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.

          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.


Søren