Re: penalty for double buffering

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.


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