composite manager and memory mgmt

[Felix Bellaby]

On Thu, 2007-03-22 at 15:39 +0200, Tapani Pälli wrote:
> Hello,
> I'm trying to build a sort of 'resource friendly' composite manager for
> Maemo platform, code is based on xcompmgr code. I added another thread
> that does some memory management keeping up a 'reasonable cache' of
> renderpictures. Basically it frees pictures for every application window
> that is not currently visible on the screen (pictures for windows that
> are under current application window [1])
> 
> Do you think this is a good approach? Should I free memory only when
> something happens ('event based') or is threading safe option here?

When you redirect a window using XComposite then the X server will
allocate a new pixmap whenever the window is mapped and the X client
will draw into that pixmap. The server maintains its own handle to this
pixmap. The compositor normally obtains a handle to this pixmap for its
own use by calling XCompositeNamedPixmap. The pixmap remains allocated
until both of these handles have been released.

The server releases its handle when the window is unmapped or
unredirected. The compositor releases its handle by calling XFree.

I suspect that you are performing an XFree on the compositor's pixmap
handle while the window is _still_ mapped. This will not deallocate the
memory used by the pixmap. Instead, it will introduce an unnecessary
overhead when the next time that you call XCompositeNamedPixmap. This
overhead is quite large on some platforms.

The compositor can only deallocate the pixmap memory after the window
has been unmapped or unredirected. The compositor will normally lose
interest in the pixmap shortly after the window is unmapped or
unredirected and it should wait until then before performing an XFree.

Hope this helps.

Felix