"Novell is announcing its contribution of the Xgl graphics subsystem and the 'Compiz' compositing manager to the X.org project. These enhancements open up a whole world of hardware acceleration, fancy animation, separating hardware resolution from software resolution, and more. As a result, Linux desktops will become more usable, end-user productivity will increase, and Linux is firmly positioned at the forefront of client computing technology." Videos and screenshots are included in the press release. And on a related note, Dan Winship of Novell has explained on gnome-desktop-devel why Novell worked on all this behind closed doors-- and this also applies to the striking similarity between Novell's mockups from December and Nat Friedman's videos. The changes made to GNOME will all be released back.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-01-07
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).
Member since:2005-07-06
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.
Member since:2005-07-07
Member since:
2005-07-08
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.