On 29 January 2010 03:54, Andrew Cowie <andrew@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 2010-01-28 at 08:08 +0000, jcupitt@xxxxxxxxx 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 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
