The All-Singing, All-Dancing XCompMGR

[Jon Nettleton]

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

Jon