Because of the asynchronous nature of X11, it has traditionally been hard to make sure that the contents of a window synchronizes well with the window border while resizing. To solve this, a window manager protocol was developed that allowed the application to inform the window manager about when it had finished dealing with the resize event. This is known as the _NET_WM_SYNC_REQUEST protocol.
Until now, Qt has not officially supported this protocol, although there was a patch that adds support for it in the KDE copy of Qt 3. What bugged me about this was mainly that it caused resizing to be unnecessarily slow on the GNOME desktop, since Metacity will only send resize events at a fixed slow interval for applications that do not support this protocol, no matter how simple your dialog. I never did any X11 programming before, so I joined forces with Matthias and Denis and together we worked towards this patch, which adds support for the _NET_WM_SYNC_REQUEST to Qt 4.6.
Demonstrating resizing got smoother on GNOME
As a bonus, this fixed the disturbing resize behaviour when running with Compiz (visual effects). As became clear, Compiz relies heavily on this protocol to provide perfect synchronization between the application and the window border.
Demonstrating smooth and solid resizing on Compiz
Finally, I will note that waiting on the application does of course not come without drawbacks. For complex applications like for example Qt Creator, we have noticed that the resizing can also feel slower. This is because the window frame is waiting on the application to catch up, which increases the desynchronization with the mouse cursor. We’re not sure what is better in this case. I know I personally would prefer my frame to resize as fast as possible, without taking into account the application at all. But that should in my opinion be a window manager option.
For those who would like to try it out live but don’t want to go through the trouble of compiling Qt themselves, I’ve built two static 32-bit binaries; one that has the patch and one that doesn’t. Even though they are built statically against Qt, they will still need some other libraries available on your system, just see if it works for you (tested on Ubuntu Jaunty).
Possibly related posts:
17 comments
Very very nice work! Thank you!
Under compiz now the resizing is just smoooooooooth…
Anyways I always wonder why QT or GTK don’t resize as smoothly as Cocoa in Mac does.
Can I ask how you made the videos? I’ve been struggling to do this under Ubuntu, all the tools I’ve used produce a flickering mess!
Resizing the xsync build seems to become enormously slow after resizing it for a while. On KDE 4.2.4 with Desktop Effects enabled. The no-xsync build still behaves fine after a similar amount of resizing.
Pellaeon: I cannot reproduce it with neither metacity nor compiz, so it could be a problem in kwin. (I’d say the NET_WM_SYNC_REQUEST protocol doesn’t seem to make window resizing in kwin more smooth at all).
I have the same problem as Pellaeon: There has to be a bug in the application.xsync programm tested under kde 4.2.4. The resizing starts quite fast but then after about 5 seconds of continous resizing over the whole desktop the application starts to be very slow.
Btw, the captcha was three times too hard for me. It is indecidable wther one has to use o or O or 0. Same with other usual suspects.
Hell, yes – thanks for spending your time on this, it looks much improved!
@Pellaeon and Christoph:
Could it be that you resized the window to its minimum size? If so then it will most likely be related to https://bugs.kde.org/show_bug.cgi?id=183263 .
This happens even if I do not resize the window to its minimum size. For example my window stays at least 500×500 pixels and it starts to get slow.
@Menda: me too. I’d love to see the smoothness of cocoa under X11. In the meanwhile, this is a very good improvement
@Paul Dixon: I used the command-line ‘recordmydesktop’ tool, easily installable in Ubuntu and doesn’t produce flicker for me. It has several nice options, for example recording only a part of your screen or recording the video at a high framerate. The command I used was “recordmydesktop -fps 60 -width 1024 -height 576 -y 200″.
I see the same slowness problem with KWin 4.2.2. I hope with this patch out people will soon be able to get to the bottom of that.
As for Mac resizing being smoother, for years whenever I saw a Mac I was appalled by how slow window resizing was, but it seems recent Macs have really improved in that regard. It’s all about accelerating the appropriate operations in graphics hardware. X11 is still struggling to adapt the protocols and APIs used for accelerated drawing, and the main graphics card vendors are only doing the minimum necessary to keep up. Time will tell when this will change.
Thanks for the info, will check it out.
The demo worked well on my fairly modest Ubuntu Jaunty system. The no-sync version was acceptable, but the sync version was very smooth.
Are you talking about resizing ? Are you serious??????????
OMG… windows and mac os x had this stupid thing like for a thousand years….
Jesus… no wonder linux/kde/gnome cannot and will never take the market.
I don’t see a difference. The border at the bottom of the patched window still changes in size during the animation. This is very bad.
@Fischlustig: That’s a window manager issue that Qt can’t fix. Also, it’s basically impossible for the window manager to solve this without compositing. In the second video you can see that Compiz (a compositing window manager) does sync the border perfectly, at the expense of lagging behind the mouse a bit.
@dude: Windows and Mac graphics protocols are synchronous, X11 is not. That’s the whole issue described here. On the other hand you can run a graphical application remotely very efficiently which isn’t so important nowadays but it used to be crucial in the times the X protocol was developed. X is now outdated and there is work under progress to find a replacement for it but this is not a trivial problem. Currently we have to live with workarounds.
Where to put the files in the tar archive you posted?
Comments on this entry are closed.