Idea how to fix slow window resize in a composited desktop

[David Reveman]

On Mon, 2007-09-03 at 13:52 +0200, Dennis Kasprzyk wrote:
> Hi,
> 
> I think that I have found a solution for the slow window resize in a 
> composited desktop environment. I don't know enough about the xserver 
> internals to say that my idea will work, but I would like to share it with 
> you.
> 
> To prevent the need the reallocation of new window pixmaps on the xserver side 
> and it's handling on the composite manager side during a frequent window 
> resize, we could redirect the drawing of the window to a pixmap that is 
> bigger than the window:
> 
> - The composite/window manager uses XCompositeNameWindowPixmap for the normal 
> window handling.
> - If the user clicks on a window edge (=wants to resize a window), then the CM 
> creates a big (screen size?) pixmap and calls a new 
> XCompositeAssignPixmapToWindow function and frees the old window pixmap.
> - The xserver copies the content of the window to the new pixmap and redirects 
> all drawings to the new big pixmap.
> - As long the window fits into the big pixmap all resizes will directly go 
> into it. If the window gets bigger than the current assigned pixmap, then the 
> CM will need to create a bigger pixmap or switch to the current 
> XcompositeNameWindowPixmap handling.
> - If the user releases the window edge (=terminated resizing) then the CM can 
> call XCompositeNameWindowPixmap to get a window sized pixmap and can free the 
> big one.
> - The xserver can then copy the window content from the big pixmap to the new 
> window sized pixmap.

Sure,

I've been thinking about re-parenting client windows into a larger
(screen-size) top-level window while resizing them. This should give the
same result as what you're suggesting but without the need to add a
XCompositeAssignPixmapToWindow request.

It shouldn't be very hard to make the compiz resize plugin support this
and it would be interesting to see what kind of performance improvement
it could provide.

-David