Resizing and scrolling very slow when running a compositing manager

[Pasi Savolainen]

Carsten Haitzler (The Rasterman) <raster at rasterman.com> writes:

> On Tue, 25 Apr 2006 08:30:59 -0600 Brian Paul <brian.paul at tungstengraphics.com>
> babbled:
>
>> Matthias Hopf wrote:
>> > On Apr 25, 06 14:21:21 +0100, Ioannis Nousias wrote:
>> > 
>> >>>I have a Radeon 9200 Mobility and I'm running Xorg 7.0 with radeon driver.
>> >>>If I run a compositing manager like xcompmgr, scrolling and resizing
>> >>>windows is much slower, especially for applications like Firefox. I
>> > 
>> > 
>> > 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?
>
> 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
> 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
> section to a tmp buffer before a transformed operation... ? though this will
> make transformed ops qith xrender more expensive by the addition of a
> linearize. (you can keep a linearized cache too i guess...). then there's
> hybrid approaches to...

Would it make any sense to allocate 'as large as possible' texture right
at the beginning of resize and just reallocate it as a close fit in the
end?

-- 
   Psi -- <http://www.iki.fi/pasi.savolainen>