CPU usage shoots up when opening new tweet box

[Bilal Akhtar]

Look at the attached image. What I've done is, I've first opened the New Tweet box, closed it after a few seconds, and then opened it again after a second or two (its open at the time of taking the screenshot). Now look at Gnome-system-monitor in the same screen shot. Its clear that during the first duration when the box was opened, CPU usage of a core went around 75% up (the orange line), and it also took usage of a core half-up (the red line). Closing the box then brings usage back to normal.

The CPU sport happens without the need to type anything into the box. Just opening it increases the CPU usage, and it isn't clearly evident what Gwibber is trying to do in the background, since nothing in the gwibber window changes.

Steps to reproduce:
1) Open Gwibber
2) Open Gnome-system-monitor
3) Click the new tweet button at the top right in the gwibber window.
4) See CPU usage rise up.

Expected result:
CPU usage shouldn't stay risen when the box is open.

Actual result:
Just opening the box up brings the CPU usage up, and it doesn't come down until the box is closed.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ken VanDine (ken-vandine)]

This is caused by keeping the input entry transparent, if we can't get the load down we should drop the transparency.

[Bilal Akhtar (bilalakhtar)]

I don't think most users care too much about transparency, as they would about CPU usage. Well, that's probably just me. Anyone?

Since right now, when I open up the box, CPU usage shoots up so much that Unity's launcher hide/unhide lags quite much.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gwibber - 3.2.1-0ubuntu2

---------------
gwibber (3.2.1-0ubuntu2) precise; urgency=low

  * debian/patches/lp_861903.patch
    - Revert fix for bug 812039 which caused a loop which drives CPU usage up
      when the entry is being displayed. (LP: #861903)
 -- Ken VanDine <email address hidden> Wed, 26 Oct 2011 12:19:48 -0400

[Martin Pitt (pitti)]

Ken, please reupload the oneiric SRU with -v to include the previous changelog.

[martincasc (martincasco)]

Unfortunately this bug i present in Gwibber 3.2.1

[Martin Pitt (pitti)]

Hello Bilal, or anyone else affected,

Accepted gwibber into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[martincasc (martincasco)]

Solved. Core i3, 4Gb RAM, 64 bits. :D

[Launchpad Janitor (janitor)]

This bug was fixed in the package gwibber - 3.2.1-0ubuntu1.2

---------------
gwibber (3.2.1-0ubuntu1.2) oneiric-proposed; urgency=low

  * debian/patches/lp_861903.patch
    - Revert fix for bug 812039 which caused a loop which drives CPU usage up
      when the entry is being displayed. (LP: #861903)

gwibber (3.2.1-0ubuntu1.1) oneiric-proposed; urgency=low

  * New upstream release
    - don't block the UI loading when creating the model (LP: #864727)
    - Add an index to speed up retrieving messages (LP: #864727)
    - Added profiling output
    - only disconnect valid handlers
    - lens: ensure we refresh the results when the lens becomes active, but
      only if the stream_model has changed
    - lens: don't clear the results model on an invalid search
 -- Ken VanDine <email address hidden> Wed, 26 Oct 2011 12:07:31 -0400

[James Hunt (jamesodhunt)]

Fix mentionws in #10 does not work: this bug still exists in gwibber 3.2.1-0ubuntu1.2.

Thankfully I've got a few cores, but it almost maxes out 2 of them and my fans go crazy when I click new message.

[Damien Lecan (dlecan)]

Issue fixed for me with Gwibber 3.2.1

[J. Austin Rodriguez (jeanaustinr)]

Fix confirmed. Good job!