Breaking the X module ABI in 7.0 ?

[Owen Taylor]

On Mon, 2005-04-11 at 20:16 +0200, Roland Mainz wrote:
> Owen Taylor wrote:
> > > I have another example where this starts to hurt: Memory fragmentation.
> > > Currently the number one problem for long-running Xservers or Xservers
> > > running in memory-restricted environments such as Xterminal/Thin clients
> > > is memory fragmentation. Where does this fragmentation come from ? The
> > > primary source of this problem are pixmap allocations (well, teaching
> > > the GTK+ toolkit or Mozilla not to abuse pixmaps for obscure things such
> > > as double-buffering (ignoring the detail that there are the
> > > DOUBLE-BUFFER and MultiBuffer extensions) is likely not an option... ;-(
> > 
> > There's no reason why the GTK+ use of pixmaps for double buffering
> > (which is the right way to do things, I'd claim) should cause memory
> > fragmentation ... it allocates *one* pixmap, draws to it and then
> > frees it. Even the worst possible allocator (and the current scheme
> > isn't much better than that) should do OK there.
> 
> It does OK if you have one single application which behaves like that.
> But a full desktop with lots of GTK+ clients causes the
> allocations/deallocations from various clients to interleave with each
> other.

Even in a repaint-the-desktop situation, once things go idle, all the
GTK+ double buffer pixmaps will be freed. You could could certainly have
problems if while GTK+ has memory allocated, another client allocates
some small persistent pixmaps, but for that problem I don't see
a big difference what the timescale of the GTK+ allocations are for
that.

(I don't think the glyph bitmaps for RENDER/Xft will end up in video
memory since they are a different depth than the frame buffer, so they
shouldn't cause fragmentation problems.)

> > (No interest in making every GTK+ program permanently use huge amounts
> > of memory to maintain persistant back buffers. There are some
> > interesting things that can be done with Composite,
> 
> One possible proposal would be to keep the pixmaps for backbuffers until
> the application has become idle and not allocating it for each single
> buffering operation (e.g. sort-of a client-side pixmap cache to remove
> some load from the server-side memory allocator).

All repainting (more or less) in GTK+ is done at idle, and a single 
double-buffer pixmap is allocated for the entire repaint operation
on a window. You could do a little better by sharing a double-buffer
pixmap between parent and children, but the depth of the GTK+ drawing
stack is typically pretty shallow. A GTK+ window has few input-output
sub-windows.

> > but I don't think
> > there's much or any applicability of the old buffering extensions to
> > that.)
> 
> Did anyone from the GTK+ people looked into using DOUBLE-BUFFER or the
> MultiBuffer extension yet ? Long ago I made a quick hack to make Mozilla
> use the MultiBuffer extension and it improved the situation a lot (since
> then some things have changed, incl. the detail that Mozilla now
> deallocates/allocates the backbuffer less often, more or less
> implementing the proposal above).

I've read over the specs a while ago, and they didn't seem particularly
useful to me.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-arch/attachments/20050411/7e02edfa/attachment-0001.pgp