Resizing and scrolling very slow when running a compositing manager

[David Reveman]

On Tue, 2006-04-25 at 08:30 -0600, Brian Paul wrote:
> Matthias Hopf wrote:
> > On Apr 25, 06 14:21:21 +0100, Ioannis Nousias wrote:
> > 
> >>>I have a Radeon 9200 Mobility and I'm running Xorg 7.0 with radeon driver.
> >>>If I run a compositing manager like xcompmgr, scrolling and resizing
> >>>windows is much slower, especially for applications like Firefox. I
> > 
> > 
> > It's somehow a fundamental problem. AFAIR David has already thought
> > quite a lot about it, there is no trivial fix for that right now,
> > though. The problem is that the off-screen surfaces have to be resized,
> > which is a costly operation. It's also expensive on higher end hardware,
> > just not as noticable.
> > 
> > I think in the near future the resize plugin can do something about it
> > (an intermediate off-screen surface during resizing, doing the final
> > size in the very end), but nothing right now.
> 
> In another project I had to resize off-screen Pbuffers in response to 
> window size changes.  I allocated my Pbuffers at a multiple of 32 
> pixels.  Therefore, changing the size by a small amount didn't require 
> reallocating the Pbuffer.  Seemed to work pretty well.
> 
> Is XGL doing anything like that?

No. For accelerating RENDER properly and for GLX_EXT_tfp, textures that
represent pixmaps must have the exact same size as the pixmaps,
otherwise e.g. texture wrap modes and texture coordinates don't work
correctly.

We could do something like this when using pbuffers as we then copy from
pbuffers to textures but we still need to allocate a new textures and as
FBOs are preferred, I don't think it's worth the effort.

-David