Idea how to fix slow window resize in a composited desktop
davidr at novell.com
Thu Sep 6 13:01:52 PDT 2007
On Mon, 2007-09-03 at 13:52 +0200, Dennis Kasprzyk wrote:
> 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
> 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.
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
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.
More information about the xorg