The All-Singing, All-Dancing XCompMGR
pbrobinson at gmail.com
Mon May 3 06:40:47 EDT 2010
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
>> 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
More information about the Devel