OSNews

All this stuff looks really smooth and whatnot.. but even in one of those videos on the novell site you can see that resizing a window is still dog slow.

It did seem slow, but this is in fact a lot more complicated than you claim. Moving objects in 3D, compositing them is a lot simpler than changing their geometry and remapping their surface.

I imagine someone is working on it, but whatever happens resizing is always going to take more juice than moving them and/or applying an alpha channel.

I know it's technically probably a very difficult thing to do/fix. I didn't mean to call it "simple" in that way, but for me, as a stupid end-user, it's one thing that stands out as an issue.
Well, I hope that there's someone working on it somehow. I just never see anyone actually mention anyting about resizing windows and I'm afraid that's why it's not a high priority issue..

There is no magical solution to make resizing fast, since the whole window content has to be recalculated (not just scaled) constantly. Depending on the complexity of the content this can be either fast or slow. Compositing doesn't help at all with this and it will likely never be lightning fast. It can only remove the flickering, so it appears more "solid".

I personally don't see why this should be a big deal. I'm not constantly resizing windows, so I don't mind if it looks slow as long as it's reasonably responsive.

Actually compositing made it worse. It doesn't need to be lighting fast, but just as fast that the window follows the cursor in a somewhat fluid way.
I, for one, resize my windows all the time and for me it's just not reasonably responsive. I know this is a very subjective topic but I think right now (with compositing) it's just unbearably slow (close to being broken).

Resizing on X is a bit more complicated than it seems. Reflow (the computation of the new window contents) is actually fairly low on the list of problems. Notice how applications that have slow resize on Linux (eg: Firefox), have very smooth resize on OS X or Windows, even though the reflow code is the same on both platforms.

The real problem is synchronization. The window manager and client aren't synchronized during resize, which hurts things enormously. In theory, there is a NETWM spec to achieve this synchronization, and I had a Qt/kwin patch that implemented the spec to good effect (at least on my 2GHz P4 laptop) to make resizing smoothness fairly comparable to Windows. My motivation to finish the patch is unfortunately very limited, given I don't use KDE anymore.

GTK/metacity have an implementation of the spec as well (included since GNOME 2.8 or 2.10, I think), but its results are much less impressive than on KDE. I don't know the GTK source code all that well, but my guess is that GTK's rather aggressive buffering and combining of EXPOSE events actually hurts redraw latency in order to minimize overdraw. Qt's redraw model, in contrast, is very simple and low latency, at the expense of having more overdraw. I'm inclined to argue that Qt's model is better, given that the "feel" of responsiveness is entirely dominated by latency.

All that aside, its become apparent to me that synchronization isn't super-useful without full use of compositing. No matter how fast the app handles content reflow, and no matter how well the application and window manager are synchronized, the user will still see an ugly (if fast) resize unless the process is double-buffered. The last time I looked into the issue, COMPOSITE wasn't fully able to support the window resize semantics necessary for double-buffering resize (you need to be able to seperate the allocation of the new window buffer and the deallocation of the old one, and during the resize itself have a handle to both copies), though this feature might have been added recently. Of course, implementing it efficiently is another can of worms --- allocating/deallocating all those buffers during a resize demands a lot from the memory manager, and video memory management is a current trouble area for X.

Ultimately, getting smooth resizing is going to involve a combination of proper synchronization, double buffer, and good resize handling in the toolkit. With those factors in place, resize will become reflow limited, which shouldn't be a problem for the vast majority of applications. Unfortunately, all these pieces could take awhile to fall into place. I believe Reverman's work implements the synchronization spec, but I don't know if double-buffering is handled very efficiently, and I'm pretty sure GTK+'s handling of resize events hasn't improved any lately. A major hurdle has been graphics drivers, since the lack of good open-source drivers for modern cards has meant that its been very hard for X developers to experiment with ways to get the graphics driver to cooperate with the double-buffered windowing system.