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

[Carsten Haitzler (The Rasterman)]

On Thu, 13 Jul 2006 13:41:42 +0100 Felix Bellaby <felix at bellaby.plus.com>
babbled:

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

but if you want "expose" "live icons" (icon updates while app is minimized) you
need to keep the pixmap around - that is what i am talking about :)

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

depends on what you are doing - what if i have a pager that displays a perfect
miniature of each virtual desktop - LIVE with windows updating in each?
perfectly feasible with xcomposite these days, and users actually have
expressed a desire in it and it has a use (you can see the apps on other
desktops finish their work or update and then you know if you should go have a
look at them or not). this case would eat up an absolute boatload of video ram.
and trust me - that is not far down the road :)

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

indeed - though being smarter about it means we can lower the entry point - by
a long way. i think that is important.

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

indeed - that was the original topic - unfortunately there is a hole with it
that still requires invisible copies of the data before the compositor sees it
to avoid nasty artifacts during updates. :(

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)