composite manager and memory mgmt
Felix Bellaby
felix at bellaby.plus.com
Fri Mar 23 05:23:02 PDT 2007
On Fri, 2007-03-23 at 09:23 +0200, Tapani Pälli wrote:
> > 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.
> >
> >
>
> OK, this is interesting. I haven't touched the pixmap resource through,
> I'm currently trying to free the unnecessary Render pictures created and
> managed by composite manager as these ones are not freed even though
> window would not be visible, they are freed only when unmapping window.
The window render pictures are not really worth deallocating. They
comprise a relatively small structure allocated in the X server which
contains another handle to the named pixmap. You need to do an XFree on
them after the pixmap is no longer required so that the pixmap memory
can be released in the X server. However, there is little point freeing
them so long as the pixmap continues to exist.
On the other hand, there your compositor might use other pictures, like
the shadow pictures used by xcompmgr. There might be a case for freeing
some of these pictures while a composited window remains mapped.
> > 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.
I should have mentioned that the server also discards its handle to the
named pixmap when the composited window is resized, not just when it is
unmapped or unredirected. A new pixmap is allocated within the server
for use in rendering the window after the resize and the compositor will
need to replace its old pixmap using XCompositeNamedPixmap before it can
show the new contents.
> I'm trying to build some logic to have images available even after
> window is destroyed, currently I'm doing this by having Render pictures
> for those ones I want to save. But it seems I could keep using the named
> pixmap.
That should be all that you need to do.
BTW, you seemed to imply earlier that your compositor only shows one
maximised window at a time. If this is the case then what useful
function is your compositor performing?
Felix
More information about the xorg
mailing list