Idea how to fix slow window resize in a composited desktop
onestone at opencompositing.org
Wed Sep 26 06:41:39 PDT 2007
Am Donnerstag 06 September 2007 22:01:52 schrieb 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.
> 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.
I've tried to implemented this idea (only as a quick dirty test) and the
performance improvement was minimal. The resize performance is still really
slow compared to the non composited resizing.
More information about the xorg