Resizing and scrolling very slow when running a compositing manager

[Brian Paul]

Xavier Bestel wrote:
> On Thu, 2006-05-11 at 14:44, Rene Rebe wrote:
> 
>>>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.
> 
> 
> Not really. It's 1/32 of the former reallocation only if you move your
> mouse slower than 1 pixel/frame (assuming everything is fast enough,
> otherwise you have to move enven slower). In real life, you move far
> faster and so loose much of the benefits of your 32-pixel-at-a-time
> allocations.

Well, I often find myself resizing windows just a small amount (trying 
to squeeze a lot of xterms on my screen, ya know).  When resizing is 
sluggish, this simple task can become frustrating.  Rounding up the 
window size to 32 (or 64 or 128 or whatever you want) makes this 
noticably snappier/smoother.

Like I said, I've actually done this in a project and it really does help.


> Just allocating once the maximum size (i.e. the size when the mouse
> cursor is at the bottom-right corner of the screen) seems a much better
> strategy.

I think that would work, but it also seems excessive.

-Brian