After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704502 - Workflow-crushing lag when searching for applications
Workflow-crushing lag when searching for applications
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: overview
3.8.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2013-07-18 20:28 UTC by Yann Bane
Modified: 2014-04-26 15:22 UTC
See Also:
GNOME target: ---
GNOME version: 3.7/3.8


Attachments
The screen where the lag happens. (1.08 MB, image/png)
2013-07-18 20:28 UTC, Yann Bane
Details

Description Yann Bane 2013-07-18 20:28:40 UTC
Created attachment 249570 [details]
The screen where the lag happens.

I am experiencing a 4-to-6 second lag (rough estimation) when trying to search for applications in the overview.

This is the detailed scenario:

1. I'm working in some window, and decide that I need to search for an application and open it.
2. I press the Super (Win) key, and the overview is shown (no lag here).
3. I start typing  - LAG

When I type the first letter, the initial set of applications appear on the screen virtually instantly. However, gnome-shell starts lagging then, no matter what I do.

Trying to quit the overview dos not help, everything is simply stalled for a few seconds.

Also, most animations, in the overview, the regular view, and windows, work just fine, so I doubt this could be GPU driver-related issue.

I am experiencing this on a completely new Fedora install, and the only modifications I have made to gnome-shell is some configuration with the GNOME Tweak Tool. I have no extensions installed.

I have the HP ProBook 4530s laptop.

SYSTEM INFORMATION:

uname -a

Linux lt1 3.9.9-302.fc19.x86_64 #1 SMP Sat Jul 6 13:41:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux


head -n1 /etc/issue

Fedora release 19 (Schrödinger’s Cat)


grep "model name" /proc/cpuinfo

model name	: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz
model name	: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz
model name	: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz
model name	: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz


Please see this document for more hardware information: http://pastebin.com/xuBvTLnZ (output of sudo lshw).

I honestly hope this is fixed soon as I really like GNOME.

--

I would've filed this as a MAJOR bug personally, but since this is my first time reporting a bug with this system, I left it at default. If possible, please change its severity to MAJOR, as this really is a major bug (although it doesn't cause crashes, which might be a criteria for a MAJOR bug).
Comment 1 Yann Bane 2013-07-19 09:16:14 UTC
I've found the equivalent bug report on the Fedora downstream: https://bugzilla.redhat.com/show_bug.cgi?id=964764.

The bug report suggests that the lag only happens when the user is logged into an online account and his status is set to "Online".

As confirmed by my attached screenshot, my status was set to "Online", and I was logged into Google and Facebook.

I have still not confirmed whether setting the status to something other than "Online" actually removes the lag.
Comment 2 Rui Matos 2013-08-13 16:01:11 UTC
(In reply to comment #1)
> I have still not confirmed whether setting the status to something other than
> "Online" actually removes the lag.

Did you end up checking this?
Comment 3 Yann Bane 2013-08-13 19:51:05 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > I have still not confirmed whether setting the status to something other than
> > "Online" actually removes the lag.
> 
> Did you end up checking this?

The issue now seems largely fixed.

I logged into Google and Facebook, set the status to 'Available', and I could experience no lag with searching.

Has it actually been fixed, or is this just an anomaly?
Comment 4 Florian Müllner 2014-04-26 15:22:10 UTC
Closing as of comment #3.