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

[Felix Bellaby]

On Thu, 2006-07-13 at 22:24 +0900, Carsten Haitzler wrote:
> > 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 :)
>
> ...
>
> 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 :)

Well, they must have good eyesight. :) 

Compositing using pixel perfect framebuffers for each application just
to shrink them to nothing would indeed be extremely expensive, but
speeding up the drawing into those framebuffers would be a rather feeble
gesture towards efficiency. Pixel operations can not be performed
remotely efficiently at entirely the wrong scale. You would be much
better off switching to a scalable drawing API like cairo for _this_
kind of work. 

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

The copies of the data can either occur before the compositor sees them,
as they have been implemented in gtk, or they can occur within the
compositor, as extraneous factors have been forced me to implement them.
Given my poor understanding of the mystical processes that occur within
nvidia and ATI, I remain somewhat agnostic concerning the relative
merits of these two possibilites. 

Your approach reduces the total memory that needs to be allocated at any
specific time by allowing the toolkit to choose when to buffer and which
areas to buffer. However, nvidia seem to be confessing that this memory
will currently be alloced and dealloced in RAM and the drawing
operations will make little use of the GPU. 

My approach maximises the total memory that needs to be allocated by
using a texture to buffer the entire window pixmap. However, when the
GPU is being underutilised, then this memory should be located in VRAM
and the drawing operations may make better use of the GPU.

This suggests that high end GPUs might be able to benefit from
compositor based buffering, just as low end GPUs have benefitted from
gtk buffering for many years. However, I will need to see a lot more
evidence of high end GPUs compositing at high speeds before I take this
side of the argument as seriously as the other.

Felix