Performance change from X in Fedora Core 4 to Fedora Core 5

Felix Bellaby felix at
Thu Jul 13 05:41:42 PDT 2006

On Thu, 2006-07-13 at 19:33 +0900, Carsten Haitzler wrote:
> a composit manager
> doesnt know when you run out of video ram. it doesn't know if it should free up
> pixmaps for iconified/minimized windows (it is keeping around so "expose osx
> like things can work). 

Xcomposite frees its pixmaps when windows are unmapped, and composite
managers should release any other storage at the same time. I presume
that XComposite only creates a new pixmap when the window is remapped,
since it would be completely pointless creating one until then. 

> performance drops like a stone to the bottom of a very deep river.
> we do need to consider conserving video ram. as resolutions go up (1920x1200
> and up) and people do twinview/mergedfb etc. and now have even more screen
> realestate... and they like to run lots and lots of apps - like they always
> have done... dozens and dozens of xterms over many virtual desktops across
> mutliple monitors...

I am not sure what XComposite does with pixmaps for windows on invisible
virtual desktops, but it would be wise for it to treat them as unmapped
and throw away the pixmaps.

Still, even with those caveats, I agree with Carsten. Compositing is an
incredibly expensive and inefficient approach when it comes to video
memory management. The lack of optimised direct rendering and the use of
GL texture mapping are other major factors slowing it down. 

All in all, I would not recommend compositing to anyone seriously
interested in video performance. It is something nice for your desktop
when you have lots of spare GPU capacity and performance is of little

If we seriously want to go 3D then we need to forget about giving apps
their own framebuffers and do something extremely radical. For example,
rewriting all the toolkits to send 3D models to a rewritten server that
composes them into a GL scene.

However, the issue that we were addressing here was whether all the
expensive buffering involved in compositing might provide a means of
avoiding doing the cheaper buffering done without compositing. Doing
things twice over is never more efficient than doing them once.


More information about the xorg mailing list