Resizing and scrolling very slow when running a compositing manager

[Brian Paul]

Rene Rebe wrote:
> Hi,
> 
> On Thursday 11 May 2006 14:34, Matthias Hopf wrote:
> 
>>On Apr 26, 06 08:56:30 +0900, Carsten Haitzler wrote:
>>
>>>>>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?
>>
>>Not as far as I know.
>>If a window remains the same size, the allocated memory should be as
>>small as possible. It also won't help much with the effect you're
>>seeing, because during resizing you constantly have changes >32 pixel.
> 
> 
> Still this would be just 1/32 of the former reallocation and should show
> significant improvements.

Yeah, that was my point.  It _really_ made a difference.

-Brian