This occurs in Xubuntu 7.10 and 7.04 for several users at Ubuntuforums.
When for example Synaptic is launched and the password is entered the screen greys out and locks for up to 40 seconds when composite is enabled and the 'Display shadows under popup windows'-box is checked.
If the popup shadows are disabled this does not happen. Nvidia or nv driver does not make a difference, and this does not happen in gnome or kde.
Can also be reproduced with above mentioned settings, type in the terminal:
gksudo -S -d thunar
Launchpad bug report:
Thread from ubuntuforums:
user tw1ggy.ramir3z at ubuntuforums solved this by running "gksu-properties" changed "Capture mode" from enable to disable, viola!
gksu maps a fullscreen override redirect window to capture and display the content of the screen while applying a animated shade transition to black.
That causes a lot of repaints of a huge area on the screen. I cannot reproduce the issue on my laptop, but there are couple of things to try for those who have the issue:
1) What if you disable ARBG:
The use of large ARGB window in Xorg can be horribly slow and could explain such delays.
2) Does it happen with another XRender based copositor such as xcompmgr?
Bug still occurs with ARBG disabled. It seems to be happening when gksu/gksudo performs XUngrabServer(). (Is it OK that it Grabs server, pointer, keyboard in that order and unGrabs the same order?)
Anyhow, So long as "show shadows under popup windows" is enabled in XFCE compositing controls, the delay for me is anywhere from 5 seconds to over 40 seconds, average about 25 secs. It's not clear to me whether the root cause of the problem is in gksu or in the dropshadow code. It does not seem likely to be in the video code itself - I see it with Via and Openchrome drivers, others with nvidia and nv drivers.
To make clear: gksu grabs focus successfully, presents dialog box successfully, and accepts input. It is upon submission of the entered password that it hangs for up to 40 seconds with the desktop shaded and the gksu dialog frozen onscreen SOMETIMES, other times the gksu window closes but the desktop locks, still shaded, for however long. During this delay, xfwm4 and xorg are each consuming unusually high amounts of CPU time. (although the X server is frozen, no updates taking place during the delay, switching to vt1 I can see resource usage spike with 'top', and drop back to normal when XUngrabServer() releases the desktop)
The two now-established workarounds (disable popup window shadows, or disable gksu desktop grabbing) both avoid the problem, but with obvious repercussions.
Well, as already mentioned I cannot reproduce this (I am using nv).
I think this is probably the card lacking pixmap memory and the pixmaps being transfered to main mamory wich is very slow and requires a lot of CPU.
BTW, I hardly see how this could be a bug in the compositor, given the symptoms.
I have a old Nvidia GeForce 3 ti200 graphics card. I have not tried it with xcomp manager, it does not occur when using compiz in Gnome though.
To make things even more weird, i discovered that when I log in to a Gnome-session (no compiz enabled) and replace metacity with xfwm4, i get the composite shadows, but when i gksu it does not freeze like in the xfce-session.
That leads me to think that there is nothing wrong with the xfwm4 window manager/compositemanager, or with gksu.