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

[David Gerber]

On Fri, 2007-04-20 at 13:52 +0200, Kristian Lyngstøl wrote:

> 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.

What actually happens when resizing? I also find compiz noticeably
slower than eg. metacity, and that on all setup I tried (nvidia and
fglrx). The following are just guesses.

- allocate a new texture in video memory
- copy the content of the old one to the new one. How is that done? I
guess it's fast if both are in video memory anyway. Is that step really
needed? Because for example metacity doesn't display unfinished content
when resizing, that is, it seems to wait until the underlying toolkit is
done with that, and well, compiz does the same it seems
- now GTK, which uses double buffering, is rendering somewhere with the
new size. Where? Video memory or local memory?
- GTK blits into the new buffer
- the new texture is displayed

I suspect there's some local <-> video memory copying being done. One
thing I'm sure about is that if you want fast graphics you have to stay
as much as possible in video memory (you can write here but you should
avoiding reading from here at all costs).

I'm very curious about that stuff. Can someone with more clue answer the
many questions? Thanks.

-- 
Dave - http://zapek.com/