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/ _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
