When I down mouse button to move a window (I down button, move a window and stop mouse moving) the system 'breaks' for a while (rhythmbox pause, terminal window 'freeze' etc.); when mouse button up all programs 'return to life'. I've tested it several times and it ONLY freeze other programs when I disable "show window content on moving" (in "Advanced" tab of Window Manager's configuration).
Yeah, the XOR ops require a server grab that blocks other programs, this is normal. No bug here.
This isn't a bug? Programs 'pause' when I move windows and it isn't a bug? So, what is this? A feature? o.O
Okay, your remark denotes a big lack of knowledge on the subject, so let's return back to basics... 1) Why frame move mode? Because some (very) old hardware are not able to move the whole content of the windows fast enough. 2) Why is it faster to draw just a frame? Because we use XOR operations. http://en.wikipedia.org/wiki/Xor We draw the lines directly to the screen using XOR, so that when we redraw it again, the original image remains. 1 XOR 1 => 0 XOR 1 => 1 For this to work, the screen content must not change between the draws, otherwise the second XOR operation does not restore the original image. 1 XOR 1 => 0 Apps change to 1 1 XOR 1 => 0 To ensure the screen does not change, the window manager *must* grab the display to prevent other applications from changing the screen. This technique is as old as graphical environments on computers. This was used on Atari ST, on Windows, on mwm (motif WM) and basically all window manager that implements this. Without the grab, moving windows using xorg leaves artifacts on the screen everytime the content change between two XOR draws. 3) During the move my application freezes Yes, this is because of the mandatory grab. Now if audio apps freeze, then I would consider this as a bug in the audio application (Why would an audio application require to access the display, sound is not visible).
*** Bug 3895 has been marked as a duplicate of this bug. ***