The All-Singing, All-Dancing XCompMGR

[Peter Robinson]

On Mon, May 3, 2010 at 8:17 AM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
> On Fri, Apr 30, 2010 at 22:35, Jon Nettleton <jon.nettleton at gmail.com> wrote:
>>> I think our next steps should be to:
>>>
>>>  * quantify the memory difference (both total and per-window) against
>>>   not running xcompmgr.  We were already running with the composite X
>>>   extension on, so I think the increase may be small.
>>>
>>>  * work out whether we think the "frame pieces" drop shadow, and drop
>>>   shadow in general, are an improvement -- we should ask the Sugar
>>>   Design Team for their opinion on this too.
>>>
>>> Jon N, any opinions from the openchrome end on turning on xcompmgr?
>>>
>>
>> Currently compositing on the VX855 with openchrome would work, but is
>> extemely inefficient.  The openchrome support for the VX855 only
>> supports XAA until we get DRI and DMA sorted out.  Compositing on XAA
>> is really inefficient as only System Memory to VRAM actions are
>> accelerated by the RENDER extension.
>>
>> Overall compositing is visually a nice improvement, but almost always
>> at a cost of CPU and power.  I also think xcompmgr is not the right
>> piece of software.  It is really old and missing a lot of the love
>> needed for a good compositing manager to work seamlessly.  Mainly it
>> is missing un-redirecting fullscreen windows and overlays causing
>> video playback to be quite expensive, and OpenGL to be unreliable.
>>
>> Back when Thomas first wrote EXA support for the openchrome we found
>> that the bare minimum you needed for descent compositing performance
>> was 64MB of video ram.  This is doable but we also have to realize we
>> are at a disadvantage because we run at a relative high resolution
>> 1200x900.
>>
>> If we were going the compositing route I would probably suggest the
>> project look into using a simple compositing window manager like XFWM
>> from the XFCE project.  Their code was originally an import of
>> xcompmgr, but they have done a great job improving it over the years.
>> But I think that is another conversation entirely.
>
> We could reuse the work done in Sugar 0.86 when we moved to metacity
> from matchbox. Or just use metacity which is also a compositing
> windowm manager.

Or mutter which is the replacement to metacity for gnome 3 so should
be a reasonably easy swap from metacity and is used by gnome-shell and
moblin/(meego).

Peter