composite manager and memory mgmt

[Tapani Pälli]

ext Felix Bellaby wrote:
> 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
>   

With Xrestop I'm seeing actual memory being freed, for example for our
application window it's ~700kb. Could this be just 'moving' memory to
another process then? I haven't made extensive profiling with smaps yet.


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

// Tapani