composite manager and memory mgmt

[Tapani Pälli]

ext Felix Bellaby wrote:
> On Sat, 2007-03-24 at 08:52 +0000, Felix Bellaby wrote:
>   
>> On Fri, 2007-03-23 at 15:38 +0200, Tapani Plli wrote:
>>     
>>> Possible usecases are usage of shadows on application menu's and dialogs
>>> + moving elements (menus, infoprints). In Maemo we have these small
>>> infoprints (think of notifications), they can be animated (as well as
>>> have translucency) with composite.
>>>
>>> Right now I'm experimenting with menus and infoprints. Usage of
>>> composite also does some nice buffering for (complex) gtktreeviews, no
>>> more flickering white boxes then.
>>>       
>> That suggests that there is no need for the other main windows to be
>> mapped. Could you force them to unmap? It would ensure that no memory
>> was wasted maintaining pixmaps for compositing those windows.
>>     
>
> Alternatively, it might suffice to unredirect the windows while leaving
> them mapped. Providing that you use the composite overlay window for
> your drawing (rather than drawing onto root) then the overlay window
> should hide the unredirected windows, allowing you to forget about
> them. 
>
>   

This sounds doable. I was actually freeing the pixmap aswell and
therefore seeing memory freed (referring to previous mails), sorry for
confusion. I'll try unredirecting ... I was also thinking that this kind
of memory mgmt could be hooked to the extension itself (?)

> This should act as an alternative means of avoiding the allocation of
> pixmap memory for the obscured windows, though I have never tried it. It
> should be easier to implement than unmapping the windows, though it
> would probably be less efficient.
>
>   

Many thanks for the help!

> Felix
>   

// Tapani