Xorg CPU Usage much higher in Docky

[James Schriver]

The mouse animations in Docky (rev. 491) use much higher CPU in Xorg and causes a less smooth zoom animation on a mouse over. The latest revision of GNOME-Do using Docky is much smoother and uses less CPU in Xorg during a zoom mouse over animation.

See attached video for demonstration. Obviously, it is much smoother in real time, but the video running the top command can be evidenced.

Karmic 64
X 1.6.4
Nvidia
2.28.1
Mono JIT compiler version 2.4.2.3 (Debian 2.4.2.3+dfsg-2)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
 TLS: __thread
 GC: Included Boehm (with typed GC)
 SIGSEGV: altstack
 Notifications: epoll
 Architecture: amd64
 Disabled: none

[Jason Smith (jassmith)]

the higher Xorg cpu usage is due to docky 2 rendering its tooltips as external windows. Puts more strain on xorg when compiz is animating them in and out.

[James Schriver (dashua)]

Ah. Very true. I enabled metacity compositor and it is blazing fast again. Any workarounds in CCSM to have Compiz exhibit this same performance?

[Jason Smith (jassmith)]

I would disable tooltip animations? I dont know, it works fine here and
even on netbooks I have seen. I cant imagine what system it doesn't work
on...

On Fri, 2009-11-13 at 02:23 +0000, dashua wrote:
> Ah. Very true. I enabled metacity compositor and it is blazing fast
> again. Any workarounds in CCSM to have Compiz exhibit this same
> performance?
>

[James Schriver (dashua)]

Jason, would the tooltips border looking different via metacity compositor and compiz have an effect on performance with the zoom animation on mouse over? See attached screenshots.

[moebis (moebis)]

Same problem here. Running Ubuntu 9.10 default, with Compiz and latest Nvidia drivers.

When scrolling over zooming icons, CPU pegs to 100% and is extremely jerky and slow. I've been updating every new version for the last 1-2 weeks, and none of the updates have fixed the problem. I read elsewhere you thought it was an Nvidia problem, but older versions of Docky worked and other dock programs like AWN and Cairo Dock never had this problem.

[moebis (moebis)]

Still no fix? Docky now does not zoom at all, and the settings screen has the Zoom option grayed out.

[Robert Dyer (psybers)]

You are using Docky in panel mode. We disabled zoom in panel mode (at least for now) because it acts weird.

[Jason Smith (jassmith)]

The performance issues are as far as I can tell due to compiz animating the tooltips. These tooltip animations slow down the compositor (not docky) and cause it to skip frame renders even though docky is presenting them. We render a single frame of docky in under a millisecond on most hardware (mine renders in about .8ms).

[sam1234 (samburnett)]

Gtk-Message: Failed to load module "gnomenu-panel": libgnomenu-panel.so: cannot open shared object file: No such file or directory
[Info 00:05:34.627] Docky version: bzr docky r960
[Info 00:05:34.664] Kernel version: 2.6.31.16
[Info 00:05:34.666] CLR version: 2.0.50727.1433
[Debug 00:05:34.856] [SystemService] Using org.freedesktop.DeviceKit.Power for battery information
[Info 00:05:35.467] [DockServices] Dock services initialized.
[Info 00:05:35.852] Setting theme: Classic

[sam1234 (samburnett)]

Intel P4 3.06GHz
nVidia 7600GS 512MB
2X512MB DDR RAM

[Chris S. (cszikszoy)]

uhhh... sam1234, I don't think what you posted has anything to do with this bug. If you are encountering some sort of specific issue, please either open a new bug or search to see if someone else already reported the issue you're experiencing.

[Thiago Bellini (bellini666)]

I noticed something:

I have tested Docky on 4 different notebooks! All with fresh and updated Karmic Koala 64
- The first one was using a Intel hardware for graphic and Intel open-source driver It uses a LOT of CPU, but, the zoom animation went smooth.
- The second one, using an ATI open-source driver, the result was the same as #1
- The third one, using an ATI (better then the second) with a proprietary driver, the zoom animation was VERY laggy!
- The last one, using a NVIDIA proprietary driver, the result was the same as the #3

So, the laggy on animation maybe has something to do with some proprietary drivers. But, on ALL of the tests, I noticed that the zoom animation was using a LOT of CPU.

[MeRamo (igor-kandyba)]

Same problem, Nvidia graphics and Compiz. Docky is incredibly slow and increases CPU usage. It`s connected with Compiz effects enabled. To boost Docky performance just turn off all effects :) Meanwhile I switched to panel mode and no zooming effects in Docky, its running pretty fine now

[Yotam Benshalom (benshalom)]

ccsm allows turning off compiz animations based on windows' names. Is there any pattern common to all the troublesome docky tooltips, based on which a blacklisting filter can be phrased?

[Robert Dyer (psybers)]

@Yotam: You can use ccsm to grab the dock and get its title/class/whatever you want to match on. I believe all of our windows (tooltips too!) should be using the same type/class.

For me, the type is 'Dock' and the class is '/usr/local/lib/docky/Docky.exe'.

[Aarón FC (r3dd3vil2)]

Same thing here, my Xorg goes up to 80% or more when moving the mouse over Docky.
Ati HD 4650
Last privative drivers installed from official ati webpage.

[Michael (michael-maddern)]

I also have exactly the same issue. Although it doesn't just happen in compiz, it also happens with metacity when compositing is enabled. If compositing is completely disabled then it is very fast, but I get a message saying Docky needs compositing enabled.

It's definitely the tooltips causing the problems. Even with the zoom disabled, I can see the tooltips are very laggy when moving the mouse over the dock (both in compiz and metacity with compositing enabled). I also tried in compiz with all of the window animiations disabled and it makes no difference.

[Aarón FC (r3dd3vil2)]

Something else, I found that with Radeon (Open Source) drivers, it runs perfectly. But with privative drivers (fgrlx) it gets high cpu usage on xorg.

In addition, this is not ocurring only with docky. I think it's a drivers problem...

[nexus (bugie)]

I have a similar problem. Docky runs fine some time but then xorg eats up my cpu when moving the mouse over Docky. I couldn't find out yet what triggers that behavior. I tried to find an event (like lock screen) but the only thing I could recognize was that the problem is time-dependant.

[Pascal Hartig (passy)]

On my desktop computer and laptop (both with nvidia chipset) I can reproduce this bug relatively easy. I go to S3 (suspend to RAM), wake up again and mouse-over docky or trigger the auto-hiding feature. It blocks the complete Xorg for up to 20 seconds depending on how often I repeat "using" it. After a restart it works fine again for some time.
nvidia-settings tweaks did not help at all.

Can I help get this fixed by sending traces or stuff like this? It's really unusable for me, right now.

[Robert Dyer (psybers)]

ATTENTION NVIDIA USERS

Use the --nvidia flag with Docky! Otherwise you hit that fabulous Nvidia bug, which we have a known workaround for. If you don't use that flag I feel no pity for you.

ATTENTION NVIDIA USERS

[Pascal Hartig (passy)]

Awesome! I can confirm that it works. Finally, the lagging hell is over.

[Samuel (samuel-ss)]

Really works!
For people who have nvidia drives: docky --nvidia
thanks for the help Robert Dyer, but I have only one question, when restart the PC, you need to do the same command (Docky - nvidia)?

[Pascal Hartig (passy)]

Unfortunately this does not help the issues I have with some fullscreen opengl applications, especially in combination with wine. The Xorg performance with docky active decreases drastically with those.

[Samuel (samuel-ss)]

@ Pascal Hartig you do not feel any slowness in compiz with the Docky?

[James Schriver (dashua)]

Docky is still lagging with Compiz. I've tested it with Compiz ++ and 0.8.6. It is still nowhere as smooth as the original Docky 1 was. On the other hand, my $199 netbook with Intel card and Compiz runs incredibly smooth. So, it's a combination of nVidia and Compiz. I just wish there was a backport from the original Docky to Docky 2 to get this lagging/stuttering resolved. This is why I have not switched over yet on my production machine.

[Pascal Hartig (passy)]

@Samuel1988 You mean in general without additional applications? With the nvidia flag activated it's quite smooth, but sometimes - must be right before the buffer's are flushed - the performance drops. A few minutes later it gets better.

[Samuel (samuel-ss)]

@Pascal Hartig I also suffer from this problem too, but the fault is not the Docky but the nvidia drives in ubuntu, but not all drives nvidia suffer the same problem, for example I have a laptop with nvidia and ubuntu works without any problems of slowness. It has also been reported this bug, but so far nothing has resolved

[Pascal Hartig (passy)]

@Samuel1988 It was clear to me from the start that it's mainly nvidia's fault as almost all of my Xorg-related problems or stability issues, but what really bugs me is that this did not occur with the Docky version integrated in Do.

[Pascal Hartig (passy)]

I upgraded to nvidia-glx 195.* at the weekend and I had no performance issues so far, even without the --nvidia switch.

[owen.c (owen-c93)]

Using nouveau, and it still locks up my system after a short amount of time.

[James Schriver (dashua)]

Not a practical solution, but just got a new laptop with an i5 Arrandale chipset and the HD graphics run Docky/Compiz amazingly fast with the newest drivers.

[motya (motya)]

Same problem on MacBook Pro 5,3 (gf9600Gt). --nvidia flag has no effect

[motya (motya)]

Same here on MacbookPro 5,3. Ubuntu 10.4

[motya (motya)]

I mean problem exists.

[motya (motya)]

Problem exists on MacBook Pro 5,3. Ubuntu 10.4

[owen.c (owen-c93)]

lol, but yeah this is fine now now trunk.

[Viktor Ilijasic (viktor.ilijasic)]

Docky 2.1.0
bzr docky r1641 ppa

nvidia proprietary drivers.

Extreme CPU usage and big animation lag on mouseover when system is freshly started. This started after updating this evening.

Interesting part: after I do
$ metacity --replace
ctrl+z
$ bg
$ compiz --replace &

Mouseover causes no extreme CPU usage, nor is it lagging, animation is smooth and proper.

If someone would like to see this in action, I could try recording this and posting the movie.

Viktor

[Robert Dyer (psybers)]

Run Docky with the --nvidia flag.

[Viktor Ilijasic (viktor.ilijasic)]

Umm, no difference.

[Viktor Ilijasic (viktor.ilijasic)]

Happy to report that

Docky 2.1.0 bzr docky r1656 ppa
with
nvidia-current 260.19.12-0ubuntu1~xup1
on
Ubuntu 10.10 maverick
Linux 2.6.35-22-generic #34-Ubuntu SMP Sun Oct 10 09:26:05 UTC 2010 x86_64 GNU/Linux

seems NOT to be so severely affected with this bug.

Mouseover animations appear VERY smooth, although CPU usage is still high.

Now it is only a matter of optimization, visually everything works.

Not sure this is relevant to original bug, since it was in regard to a previous/old versions and releases.

Viktor

[Abdusamed Ahmed (sir508)]

I haven't read the comments but I do encounter is occasionally not frequently, docky usage just jumps to 100. I have to restart it to fix it. Not only that, just using the timer seems to spike the cpu up to.

On ubuntu 10.04.1 Docky 2.1.0 [from the official ppa]

[Abdusamed Ahmed (sir508)]

I noticed another thing, docky just idling randoming spikes xorg. Disabling some applet and helpers seems to do something but I can't confirm it.

One more thing, this should be 'important'.

Disabling Docky and starting awn seems to fix the xorg.

[Abdusamed Ahmed (sir508)]

Jut to report.. after couple of updates, it still hasn't been fixed