[compiz] Re: [PATCH] Resize improvements (Multiple resize modes, better aspect ratio constraining)

[David Reveman]

On Fri, 2007-04-20 at 13:52 +0200, Kristian Lyngstøl wrote:
> On 4/19/07, David Reveman <davidr at novell.com> wrote:
> > On Thu, 2007-04-19 at 14:01 -0300, Solerman Kaplon wrote:
> > > Speaking of that, what happened to that nice trick of creating a
> > > screen-sized texture while resizining and drawing the window to that
> > > instead of resizing the texture every single movement? I think I heard
> > > of it on the xorg list (?)...
> >
> > The server would have to be extended for that and a screen-sized texture
> > would probably not be enough as windows can be larger than that. Some
> > testing should be made first to investigate how much performance we
> > would gain and whether it's worth it.
> 
> Wouldn't the real delay be because of the excessive server-client-wm
> roundtripping that's happening, not the actual resizing of the
> texture? That seems logical to me, at least, but I'm no expert on
> this... But then again, if diffrent drivers are causing diffrent
> delay, I guess the resizing of the texture is the bottleneck after
> all, which seems strange considering the nature of the delay.

The client-server traffic has nothing to do with it, trust me.

> 
> On my nVidia 6800GT card, I can make new windows momentarily, but
> resizing them is still very lagged, and if I can allocate a new
> texutre this fast, I find it strange that I can't resize it (the
> texture) almost equally fast.

For new window to appear

1. allocate texture
2. wait for client to fill texture with contents

Resize window

1. allocate new texture
2. copy contents from old texture to new texture
3. free old texture
4. wait for client to fill new texture with contents

(how expensive step 2 is depends on whether the bits for the window
lives in hardware or software and whether the hardware can do
texture-to-texture copies)

> 
> Or is the idea to have a constant texture to resize, and let the
> content of the texture update asynchronous? So the actual texture
> appears to resize without any delay (since it isn't actually resized),
> but the content is still delayed. Causing a stretch-effect until the
> application catches up.
> 
> Or am I missing something very obvious with this idea?

The idea is just to avoid step 1, 2, 3 from above. We'll still
synchronize compositing manager drawing with client drawing so there's
no stretch-effect or anything like that.

- David