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

[Kristian Lyngstøl]

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.

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.

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?

-- 
Regards,
Kristian