Resizing and scrolling very slow when running a compositing manager

Rene Rebe rene at exactcode.de
Thu May 11 05:44:27 PDT 2006


Hi,

On Thursday 11 May 2006 14:34, Matthias Hopf wrote:
> On Apr 26, 06 08:56:30 +0900, Carsten Haitzler wrote:
> > > > It's somehow a fundamental problem. AFAIR David has already thought
> > > > quite a lot about it, there is no trivial fix for that right now,
> > > > though. The problem is that the off-screen surfaces have to be
> > > > resized, which is a costly operation. It's also expensive on higher
> > > > end hardware, just not as noticable.
> > > >
> > > > I think in the near future the resize plugin can do something about
> > > > it (an intermediate off-screen surface during resizing, doing the
> > > > final size in the very end), but nothing right now.
> > >
> > > In another project I had to resize off-screen Pbuffers in response to
> > > window size changes.  I allocated my Pbuffers at a multiple of 32
> > > pixels.  Therefore, changing the size by a small amount didn't require
> > > reallocating the Pbuffer.  Seemed to work pretty well.
> > >
> > > Is XGL doing anything like that?
>
> Not as far as I know.
> If a window remains the same size, the allocated memory should be as
> small as possible. It also won't help much with the effect you're
> seeing, because during resizing you constantly have changes >32 pixel.

Still this would be just 1/32 of the former reallocation and should show
significant improvements.

-- 
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
            http://exactcode.de | http://t2-project.org | http://rebe.name
            +49 (0)30 / 255 897 45



More information about the xorg mailing list