Resizing and scrolling very slow when running a compositing manager

Matthias Hopf mhopf at suse.de
Thu May 11 05:34:36 PDT 2006


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.

> only problem there is that then you may get "jerks" (pun NOT intended) at these
> 32pixel boundaries. it's definitely an improvement though. what about splitting
> up the surfaces into 32x32 tiles (separate textures/pbuffers). then you just

You want as few buffers as possible (reducing overhead for the OpenGL
memory allocator). Also the rendered surface has to be continuous.

> create or deleted extra tiles as needed. i know that now u have a mesh of them
> ands this might be a bit nasty on doing scaling/transform operations later with
> xrender...  just thinking out loud you can linearize the required source

This is not about the composite rendering (which would be doable), but
how to you render *into* this mesh, let alone have OpenGL render into it
(for redirected OpenGL applications)?

Matthias

-- 
Matthias Hopf <mhopf at suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de



More information about the xorg mailing list