Idea how to fix slow window resize in a composited desktop

Carsten Haitzler (The Rasterman) raster at rasterman.com
Mon Sep 3 05:52:34 PDT 2007


On Mon, 03 Sep 2007 13:52:01 +0200 Dennis Kasprzyk
<onestone at opencompositing.org> babbled:

> 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.

actually the CM could just allocate pixmaps in size steps - eg 32 or 64 pixels
in x and y - and only resize once the pixmaps goes above or below a 32/64 pixel
watermark. this "watermark" size can be configured. what you do need now is the
ability for the cm to SPECIFCY the redirected pixmaps directly, rather than
just getting it. this allows the granularity of a re-alloc to be tuned to
usage. but this is up to the CM. X just needs to make it possible via
xcomposite.

by the same toke tho - add a pixmapresize call to x protocol and then x can
internally tile pixmaps and just add or remove tiles from a pixmap as
needed... :)

> 
> Dennis Kasprzyk
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)



More information about the xorg mailing list