Idea how to fix slow window resize in a composited desktop
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Tue Sep 4 15:31:54 PDT 2007
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 (東京 日本)
More information about the xorg
mailing list