Re: penalty for double buffering

[Owen Taylor <otaylor redhat com>]

On Sat, 2003-12-13 at 17:41, Steven Jenkins wrote:
> 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.

Well, glancing at the code briefly, certainly there is no reason
to use double buffering if you are already saving using a backing
pixmap, as you are in your code.

But I wouldn't expect any significant performance impact assuming
that you have sufficient video memory. The extra copy inside the
video card will basically be free.

If you want to investigate further what is going on, I'd suggest
that the first step would be to create a small test case independent
of your application that does essentially the same thing.

If I had to make a random guess, my guess would be that there is
some pathology lurking in the way you are handling refreshes by
recursing the main loop (which is... err... odd) and that small
differences in timing are resulting in big differences in the
amount of drawing you are doing.

Regards,
                                        Owen