Description of problem:
There is a performance problem with grayed out backgrounds behind pop-up dialogs (aka lightboxes) in anaconda.
DVD (in a VM):
Everything works great, everything is super-fast.
GNOME (in a VM):
Lightboxes don't hog the CPU, but all widgets become really slow to respond. Buttons take a second or two to respond. Shrinking an existing partition in guided part dialog is really painful, the slider can't be used properly.
KDE (in a VM):
Lightboxes hog the CPU - as long as they are displayed, the CPU usage is at 100%. Widgets can be operated, but they are slow to respond, very similar to GNOME behavior. Shrinking an existing partition is painful.
XFCE (in a VM):
Lightboxes hog the CPU - as long as they are displayed, the CPU usage is at 100%. Anaconda _can't be operated_. Just the "accept my fate" dialog takes several minutes to _appear_ in a single-CPU VM (with 2 CPUs assigned it takes about 20-30 seconds). Resizing an existing partition is not possible with such a slow response.
XFCE (beefy multi-core bare metal with Intel graphics):
Lightboxes hog the CPU - as long as they are displayed, the CPU usage is at 100%. Anaconda can be operated, usual widgets are reasonably fast. However, reclaim dialog still can't be used, because on every change it takes 5-10 seconds to redraw the screen.
See the videos. In the current state, GNOME and KDE are very inconvenient to use in the reclaim dialog (particularly when shrinking); XFCE is totally unusable in VM, and very inconvenient to use in the reclaim dialog on a bare metal.
Version-Release number of selected component (if applicable):
F20 Beta TC5 DVD x86_64
F20 Beta TC5 Live x86_64 (GNOME, KDE and XFCE)
Steps to Reproduce:
1. create a VM with a single CPU (multiple CPUs speed up things a bit)
2. boot XFCE Live
3. try reclaim/shrink existing partitions
Created attachment 814581 [details]
DVD in a VM (2 cpus)
Everything is super-fast. No compositing? Different implementation of lightboxes?
Created attachment 814582 [details]
GNOME in a VM (2 cpus)
Slow during reclaim, otherwise OK.
Created attachment 814583 [details]
KDE in a VM (2 cpus)
CPU utilization is 100%, slow during reclaim, otherwise OK.
Created attachment 814584 [details]
XFCE in a VM (2 cpus)
Unusable. The end of the video is cut short, I stopped the recording. But if I had waited 20 more seconds, the reclaim dialog would have appeared.
Note: With only 1 CPU assigned, you can't even display the "accept your fate" dialog in 3 minutes of waiting.
I think this is a strong candidate for Final blocker. XFCE is not a release blocking desktop, but it completely kills it and also very noticeably affects GNOME and KDE.
I guess this is a duplicate or related to bug 1019501 ?
Kamil, you have described it beautifully in this bug report. This is exactly what happens on my laptop with ivybridge setup Lenovo Y580.
This is happenening since TC for alpha and continues to exist until TC5 beta for me.
+1 for Final blocker.
Discussed this in 2013-10-21 Blocker Review Meeting . Accepted as a freeze exception issue, as it's effectively a showstopper for installation with non-blocker desktop live images.
This has nothing to do with the lightbox implementation
*** This bug has been marked as a duplicate of bug 1019501 ***
When Vratislav Podzimek edited anaconda source code and commented out lightbox creation method, everything was snappy even with XFCE. So it is definitely related to lightboxes. I'm not saying it's an anaconda fault, it might be a gtk bug or something. But it is not an XFCE-specific thing (please see the attached videos and read the description). Because you consider bug 1019501 to be XFCE-specific (which might or might not be true), I'm de-duplicating this report again.
So, I've figured out that the anaconda_lb_configure_event is called again and again causing high CPU usage. However, it might be an issue in the xfwm4 because both anaconda and xfwm4 take ~30 % CPU, the X server another 50 %.
David, could you please have a look at this? I think we need to test if the same happens in the other window managers as well (probably not at least in metacity used for DVD installations) and reassing this bug if it really is xfwm4 specific.
That's weird, I'm not seeing the configure-event handler being called at all.
However, I do see that xfce is trying to treat the lightbox as a separate window (since we're creating it as a top level, I guess), and that could be causing problems. It might be that xfce makes the lightbox more likely to be moved/movable than GNOME does, and since we call gdk_window_restack within the configure-event handler I can see that possibly causing a configure-event loop.
It's pretty crummy performance-wise even without a configure-event loop, though.
This is a wild guess, but could this be caused by this?
IIUIC, it's a GTK regression that causes window updates even when nothing has changed.
Bastien, Owen, can you provide some advice here?
*** Bug 1019501 has been marked as a duplicate of this bug. ***
Never mind, it's the configure-event on the lightbox itself that's getting stuck in a loop; I was looking at the configure-event on the parent window. Patch posted. Try http://dshea.fedorapeople.org/updates-1021511-x86_64.img as an updates image.
Just replaced that updates.img with one that includes a patch from bcl that fixes a crash in BaseWindow that fixing the lightbox ceases to hide.
The updates.img from comment 16 was causing troubles, a fixed version is at:
I tested XFCE with it and lightboxes are super-quick again, they don't hog CPU when displayed.
I tested KDE with the update, lightboxes no longer hog the CPU. GNOME is also fine, but it was fine even before.
The resize dialog is still very slow when compared to DVD. Now when lightboxes are fixed, one can easily see that the performance is similar on all Lives regardless of environment, just DVD is super-fast. It might be still related to lightboxes, or it might be a completely different issue.
anaconda-20.25.4-1.fc20 has been submitted as an update for Fedora 20.
20.25.4-1 went stable as a part of FEDORA-2013-20033 and the fix was verified, so this can be closed.