Bug 1021511

Summary: Lightbox implementation kills performance on LiveCDs (XFCE completely unusable in VM)
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: anacondaAssignee: David Shea <dshea>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: amulhern, anaconda-maint-list, awilliam, bitlord0xff, bnocera, dshea, g.kaviyarasu, jonathan, kevin, mkolman, mruckman, otaylor, piruthiviraj, robatino, sbueno, vanmeeuwen+fedora
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedFreezeException
Fixed In Version: anaconda-20.25.4-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-06 18:08:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 980655, 980656    
Description Flags
DVD in a VM (2 cpus)
GNOME in a VM (2 cpus)
KDE in a VM (2 cpus)
XFCE in a VM (2 cpus) none

Description Kamil Páral 2013-10-21 12:41:21 UTC
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):
anaconda 20.25.1
F20 Beta TC5 DVD x86_64
F20 Beta TC5 Live x86_64 (GNOME, KDE and XFCE)

How reproducible:

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

Comment 1 Kamil Páral 2013-10-21 12:42:35 UTC
Created attachment 814581 [details]
DVD in a VM (2 cpus)

Everything is super-fast. No compositing? Different implementation of lightboxes?

Comment 2 Kamil Páral 2013-10-21 12:43:18 UTC
Created attachment 814582 [details]
GNOME in a VM (2 cpus)

Slow during reclaim, otherwise OK.

Comment 3 Kamil Páral 2013-10-21 12:44:18 UTC
Created attachment 814583 [details]
KDE in a VM (2 cpus)

CPU utilization is 100%, slow during reclaim, otherwise OK.

Comment 4 Kamil Páral 2013-10-21 12:46:34 UTC
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.

Comment 5 Kamil Páral 2013-10-21 12:48:18 UTC
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.

Comment 6 Kevin Fenzi 2013-10-21 14:09:21 UTC
I guess this is a duplicate or related to bug 1019501 ?

Comment 7 Piruthiviraj Natarajan 2013-10-21 15:53:58 UTC
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.

Comment 8 Piruthiviraj Natarajan 2013-10-21 15:55:08 UTC
+1 for Final blocker.

Comment 9 Mike Ruckman 2013-10-21 17:04:52 UTC
Discussed this in 2013-10-21 Blocker Review Meeting [1]. Accepted as a freeze exception issue, as it's effectively a showstopper for installation with non-blocker desktop live images.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-21/

Comment 10 David Shea 2013-10-21 17:26:10 UTC
This has nothing to do with the lightbox implementation

*** This bug has been marked as a duplicate of bug 1019501 ***

Comment 11 Kamil Páral 2013-10-21 17:50:14 UTC
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.

Comment 12 Vratislav Podzimek 2013-10-22 14:42:18 UTC
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.

Comment 13 David Shea 2013-10-22 21:56:41 UTC
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.

Comment 14 Kamil Páral 2013-10-23 07:15:57 UTC
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?

Comment 15 Kamil Páral 2013-10-23 15:41:55 UTC
*** Bug 1019501 has been marked as a duplicate of this bug. ***

Comment 16 David Shea 2013-10-23 18:19:39 UTC
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.

Comment 17 David Shea 2013-10-23 18:35:58 UTC
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.

Comment 18 Kamil Páral 2013-10-23 19:06:57 UTC
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.

Comment 19 Kamil Páral 2013-10-23 19:21:25 UTC
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.

Comment 20 Fedora Update System 2013-10-26 01:11:08 UTC
anaconda-20.25.4-1.fc20 has been submitted as an update for Fedora 20.

Comment 21 Adam Williamson 2013-11-06 18:08:37 UTC
20.25.4-1 went stable as a part of FEDORA-2013-20033 and the fix was verified, so this can be closed.