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. My understanding of X is sadly limited, but I'm doing my best to get across the issues. The use of Pixmaps is discussed fairly frequently in the Cairo community, with the advice being to use cairo_surface_create_similar() to get surfaces you can cache and which cairo & the X server can reuse efficiently. I wrote the documentation at [1] based on this. Doesn't mean I know what I'm talking about, but that's the best I could come up with. Anyway, is this heavy allocation behaviour expected with GtkDrawingAreas and the default double buffer implementation? 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. AfC Sydney [1] http://java-gnome.sourceforge.net/4.0/doc/api/org/freedesktop/cairo/XlibSurface.html
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
