Plank

Animation deteriorates over time

Asked by Removed by request

I am using plank for a while and I'm always on latest, using it in xfce 4.12 in Slackware current.
I set plank to have 48x48 icons that zoom on hover and the plank itself is transparent and intelli-auto-hides.
Since I started using plank some years ago until now I have experienced jittering and loss of animation quality over a time of a few days. When I restart plank the animation is very fluid but with each day or so it will look like its loosing fps to a point that within a week it runs at 1 fps or so, until I restart it again. There is no apparent stress coming from plank, it doesn't use more resources.

Compiled with:

CFLAGS="-O2 -fPIC" \
CXXFLAGS="-O2 -fPIC" \
./autogen.sh \
  --prefix=/usr \
  --libdir=/usr/lib64 \
  --sysconfdir=/etc \
  --localstatedir=/var \
  --mandir=/usr/man \
  --docdir=/usr/doc/plank-0.11.3 \
  --enable-silent-rules \
  --disable-apport \
  --build=x86_64-slackware-linux

Question information

Language:
English Edit question
Status:
Solved
For:
Plank Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Whiteboard:
Closed by Launchpad due to owner requesting account removal
Revision history for this message
Rico Tzschichholz (ricotz) said : 		#1

The linked bug is likely related while showing different symptoms.

Revision history for this message
Rico Tzschichholz (ricotz) said : 		#2

Does it make a difference if zoom is disabled?
* Does this problem still appear while zoom is disabled at start?
* Does it ease the lag if zoom is disabled on runtime while hitting this problem?

Revision history for this message
Luca Santarelli (luca-santarelli) said : 		#3

* Does it make a difference if zoom is disabled?

No discernable difference.

* Does this problem still appear while zoom is disabled at start?

Yes.

* Does it ease the lag if zoom is disabled on runtime while hitting this problem?

Unsure over the question: w/o zoom there are no animations to check the lag, however the CPU usage doesn't change after disabling zoom at runtime.

FWIW, the CPU usage is not ixed, but has some variations over a linear increase. Using "top", the CPU usage varies from 0.4-1.1 when launched. Then, as time goes by, ranges between 6-14%, 8-30%... and so on.
This has been verified w/ 0.11.4 (built from source) on a low-end notebook where Plank is not interacted with and a single Firefox window running day and night). This is puzzling me, as I'd expect the CPU usage to be constant as the app is not (actively) used at all.

Revision history for this message
Removed by request (removed3381998) said : 		#4

Wow I missed comment #2 for a while...

Currently (0.11.4) I have been using plank with zoom disabled for a few months and to me there is no loss of quality, so to me the issue is when I start it with that option enabled.
I'll recompile now (new libs in Slackware current anyway) and enable zoom and hopefully I will know more in a week.

Revision history for this message
Luca Santarelli (luca-santarelli) said : 		#5

After yesterday's message, I disabled zoom, quit and restart plank; checking today's top, I get:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21114 rina 20 0 724192 43200 13664 R 21.1 2.2 313:46.16 plank
(when top started, plank had 46% of CPU usage)
It's now ranging between 17 and 33% w/ no user in front of the computer (stats read from a remote SSH session to the host)

Revision history for this message
Removed by request (removed3381998) said : 		#6

Luca and is this better or worse than with zoom? Also I wonder if that changes over time.

Revision history for this message
Luca Santarelli (luca-santarelli) said : 		#7

It's difficult to say if it's better or worse, as the CPU usage changes every second and it takes some time to "build up".
I recompiled 0.11.0 and left the computer idle for the night (w/ plank starting at 0.9%). This morning the CPU was back to 6%.
I've now compiled 0.10.3, trying to find out the last working release and perform a git-bisect on the source.

Revision history for this message
Luca Santarelli (luca-santarelli) said : 		#8

Ok, I got it.

The deteriorating CPU issue is caused by Clippy. I am not sure as to why, because although it performs a constant costly polling of the clipboard every 500ms (twice every second!), this could explain a higher CPU usage (which is present) but not the deteriorating performance.
Amit, could you please confirm that you experience the deteriorating animations only if Clippy is present?

I have no knowledge of GTK, Vala and clipboard internals, but I'll see if I can rework the exiting code to use a listener mechanism instead of a (costly) polling one. Man, even my fingers are fast enough to update the clipboard twice in a second! :)