Re: performance problems double buffering to 1600x1200 window

[jcupitt gmail com]

On 29 January 2010 03:54, Andrew Cowie <andrew operationaldynamics com> wrote:
> On Thu, 2010-01-28 at 08:08 +0000, jcupitt gmail com wrote:
>> The built-in double buffering allocates and frees a backing buffer the
>> size of the expose for every expose event. I imagine your program is
>> spending a lot of time doing this. I suppose the gtk buffer could also
>> somehow not be in fast memory, giving you slow offscreen - onscreen
>> copies...
>
> I thought the whole idea of using Pixmaps (vs GdkPixbufs) was that they
> were in X server memory and didn't have to be copied across from
> application memory each time they were rendered.

That's right, but the X server can't always place pixmaps in fast
memory if server memory becomes very full or fragmented. It depends on
the details of the hardware and the driver.

Or that's my understanding anyway, I read a blog post by Keith Packard
a while ago that talked about how they were addressing these problems
with the Intel server.

> Anyway, is this heavy allocation behaviour expected with GtkDrawingAreas
> and the default double buffer implementation?

Yes, that's expected behaviour. It's not so usual (I think, probably
wrong) for pixmap allocate/free to be so expensive. I'll try some
timings on my machines later for fun.

> I wonder if there's some engineering we should try to do to make custom
> widgets more performant or memory efficient. It seems a touch off to say
> "use DrawingArea, but don't let it draw". Large GtkDrawingAreas are
> fairly common as "canvases" (sic) and custom widgets.

It's only large drawing areas where you are redrawing the whole
drawingarea every frame. If you just update small parts of it, you'll
only need small expose pixmaps and you won't have these problems
(hopefully).

John