Breaking the X module ABI in 7.0 ?

[Roland Mainz]

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.

> (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).

> 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).

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)