Idea how to fix slow window resize in a composited desktop

[Carsten Haitzler (The Rasterman)]

On Tue, 04 Sep 2007 12:33:13 -0400 Adam Jackson <ajax at nwnk.net> babbled:

> 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:
> 
> Yeah, this idea has come up before.  We even have the internal hook for
> this, in SetWindowPixmap.  There are some situations where we can even
> resize "for free", since most hardware has pitch or tile alignment
> constraints.  However, everything we've measured so far indicates that
> the slowest part of resizing is application reflow, not pixmap
> allocation.
> 
> It'd certainly be interesting to implement to see what the difference is
> though.

being able to have a x client (composite manager) be able to set the window
pixmap instead of x auto-allocate would be nice. then client-side can implement
whatever policy it likes (but then again it has no idea what the server-side
pitches are so it can't be automatic about picking these sizes - maybe we
should have a call to get optimal pixmap pitches in width and height? so i know
resizing to 20x20 get me a 32x32 pixmap tile anyway, and i may as well resize to
that etc.?)

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