Using higher cpu usage

[Taylor "Ripps" LeMasurier-Wren]

Binary package hint: transmission

At some point in the last month, Transmission starting using much more cpu than it used to. It now uses about 15-25% cpu, even when it's not doing anything. Also, the interface seems to have some pretty serious lag when scrolling. I don't have these problems with other programs, and the cpu usage is enough to slow some of my more cpu intensive operations, such as watching HD videos. What could be causing the this cpu increase?

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: transmission 2.04-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic i686
Architecture: i386
Date: Tue Oct 5 03:22:48 2010
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: transmission

[Charles Kerr (charlesk)]

I'm not seeing this behavior. Do you have any tips on how to make it happen?

Does it happen even if there are no torrents loaded?

[David Sugar (dyfet-deactivatedaccount)]

I do not see this behavior either. Is any of the bandwidth limiting options being selected and used?

[RedSingularity (redsingularity)]

Thank you for reporting this bug and helping to make ubuntu better. If possible can you provide a step by step guide to reproduce this bug? This will make "confirming" it a lot easier. Thanks!

[Taylor "Ripps" LeMasurier-Wren (ripps818)]

I haven't done anything. I have about 20 inactive torrents, but they are
stopped. No download/upload. Are you asking me to delete my settings folder?

[Taylor "Ripps" LeMasurier-Wren (ripps818)]

Okay, I renamed .config/transimssion, and now transmission starts up fast.
But the moment I start some torrents and pause them. The cpu jumps up to
around 8-15%, even when they aren't running. So I don't think any of my
settings have anything to do with this.

[RedSingularity (redsingularity)]

Are you looking at the transmission process under system monitor processes tab? If so, i followed what you said you have done and I don't notice a problem. CPU percentage stays in a range of 0-5%. Gnome system monitor is actually using more than the transmission client. Are you using a Fresh 10.10 install or did you upgrade from 10.04?

[Taylor "Ripps" LeMasurier-Wren (ripps818)]

Actually, I was using top from the commandline.
And I've been using Maverick since Alpha 1. Transmission only started doing
this in the last month or so.

[Krzysztof Klimonda (kklimonda)]

Do you have an NVIDIA gpu and if so are you experiencing the issue while using the latest 260.19.06-0ubuntu1 drivers, if you use the proprietary drivers at all.

[RedSingularity (redsingularity)]

It does not seem to be a reproducible bug on a freshly installed system so I cannot confirm it. How about removing the package and purging all configuration files then reinstalling? If you want you can do the following:::

sudo apt-get autoremove --purge transmission

........then search for any residual files from the program and remove if necessary

sudo find / -name transmission*

.........then reinstall the program

sudo apt-get install transmission

See if that corrects the problem.

[Taylor "Ripps" LeMasurier-Wren (ripps818)]

@Kilmonda
No, I'm using an ATI Radeon 9600 using the Xorg r300 drivers.

@RedSingularity
I did like you asked, I purged every transmission package I had installed,
and reinstalled transmission-gtk. I still get the the slow down. It seems
for every paused torrent I have added to the list, the cpu increases another
1%. The interface is really laggy, so I'm thinking this might be a gui/gtk
issue.

[RedSingularity (redsingularity)]

Ok please do the following.

1) Start transmission from the terminal and post the terminal output here.

2) While in transmission go to Edit>Prefs> And select "Limit upload speed" Make it 50 KB/s. Then quit.

3) With the upload speed changed try using the program again and see if there is a difference.

[Taylor "Ripps" LeMasurier-Wren (ripps818)]

1) There wasn't any terminal output when starting transmission, but when
closing it I got:
(transmission:19808): GLib-GObject-WARNING **:
/build/buildd/glib2.0-2.26.0/gobject/gsignal.c:2392: instance `0x9192858'
has no handler with id `725`

2) I had already had it limited to 10 KB/s, and turning it 50 didn't change
anything, neither did turning off the limiter.

I've figured out the the number of torrents affects the cpu usage. When I
only have 2 torrents queued up, regardless of running or not. Transmission
uses 4-8%, and another 1-2% is added for every torrent that is added to
list. For some reason, paused torrents are using cpu resources.

[RedSingularity (redsingularity)]

1) Start up transmission with a few torrents and paste the "top" command file here.

Do it with the following command while transmission is running........then paste the file as an attachment to the site here.

top -bn1 > ~/Desktop/Top-Command (This will put the output file on your desktop.)

2) You say the interface is laggy? This should not be the case with such a small amount of CPU usage. What graphics card is installed on your computer?

[Taylor "Ripps" LeMasurier-Wren (ripps818)]

Okay, I captured it while the cpu was spiking. It's lowest is about 4%. It had 2 torrents queued up, both of them were inactive.

As I mentioned in a previous post, I'm using an ATI Radeon 9600 Pro using the Xorg r300 drivers, default to Maverick. Other programs don't seem to be as laggy as Transmission. It's like the program itself needs a second before it will register any clicks to it.

I've started using renice on it so that everything will work more smoothly while I'm downloading torrents, but I'm going to start looking for other clients to use soon if this keeps up.

[Sherlock (shift2-freemail)]

Transmission 2.04 is also very laggy for me. The download/upload speeds are ok, but the gui is terribly slow. It takes 0.5-2 seconds while the app respond to any clicks (eg. pause/start or changing priority of files in the torrent etc. All other apps are fine.

I have an Asrock A330ION mainboard (Intel® Dual-Core Atom™ Processor 330 1.6 GHz, NVIDIA® MCP7A-ION Chipset, Integrated NVIDIA® GeForce 9 Series using DVI-I at 1400x900), 2 GB RAM, unmodified Maverick RC (updated every day), default Transmission settings (as I can recall).

Please tell me if you need more info or if I can help in any way.

[Charles Kerr (charlesk)]

would it be possible to install the transmission-debug package and then run transmission inside of valgrind?

[Krzysztof Klimonda (kklimonda)]

It's transmission-dbgsym (or transmission-dbg if you are using Transmission from the PPA). To learn how to enable ddebs repository (which is required in order to install dbgsym packages) , please refer to this page: https://wiki.ubuntu.com/DebuggingProgramCrash

[Jānis Miezītis (janjiss-gmail)]

Hi guys! I removed .config/transmission folder, that did not help me, so it is not old config fault.

Cheers,
Janis

[Charles Kerr (charlesk)]

This is a little bit of work, but judging from the duplicate tickets this is a problem for a few people, and I haven't been able to trigger this behavior yet. So if somone could try the following:

  1. Install transmission-dbgsym (or transmission-dbg) as Kryzysztof described in comment #18

  2. Install valgrind

  3. Invoke transmission from the command-line this way: "valgrind --tool=cachegrind transmission" and log a session where Transmission reports the abnormally high load. (Note: valgrind generates a *lot* of load on its own, so this step requires a little patience :)

  4. After you exit Transmission, valgrind will genrate a file named cachegrind.out.XXXX. Please attach that file to this ticket *and make sure to say what version of Transmission you used*.

I haven't walked users through this process before, so this is an experiment. Let's see how it goes.

[jrd (oberto)]

Here is my experience - incase it helps:

The interface seem extremely sluggish. Clicking, selecting, scrolling events are delayed; the menus too. Even just un-minimising cause a very noticeable delay in window redraw.

Some info:

- I upgraded from 10.04 to 10.10 (I had no problem with transmission on 10.04)
- I tried updating from their ppa to version 2.10. Still no improvement.
- I don't have proprietary driver installed (Ubuntu repo doesn't support my card - 310M)
- No other apps have this sluggish behavior.

[jrd (oberto)]

I've just removed some idle torrents from the list. Went from 13 to 3. This greatly improved response and reduced laggyness.

[Charles Kerr (charlesk)]

A user in IRC had some more information about this. After some testing, it looks like this might be an issue in the Abiance them theme. Could one or more people CCed to this list who are seeing this problem test this out to confirm/refute? That is, change the theme while using Transmission and compare the CPU use?

====

Highlights from the IRC chat:

17:00:45 < cwall> top shows transmission "taking over" -- e.g. 87% cpu on athlon 3200+ -- if I pause enough torrents. Perhaps 5% more cpu per paused torrent added.
17:20:05 <@charles> cwall: are you running the gtk client or the daemon?
17:20:13 < cwall> The gtk client.
17:20:50 <@charles> cwall: then my second question is, could you exit the gtk+ client and start running the same set of torrents in headless mode this way: "transmission-daemon -f -g $HOME/.config/transmission"
17:21:05 <@charles> that way we can find out whether the slowdown is coming from something in the gui, or from libtransmission
17:32:37 < cwall> No noticeable cpu usage with transmission-daemon; I haven't confirmed that the torrents are still paused, but I did not unpause them.
18:25:08 < cwall> # Events: 59K cycles
18:25:17 < cwall> # Overhead Command Shared Object Symbol
18:25:24 < cwall> 83.68% transmission-gt libcairo.so.2.11000.0 [.] 0x00000000017cda
18:27:14 <@charles> ...cwall a mad thought: what happens if you change your desktop theme from the ubuntu default to something else, like clearlooks
18:27:31 <@charles> on Fedora this is done via System > Preferences > Appearances > Theme
18:27:40 <@charles> probably something similar to that in Ubuntu
18:53:49 < cwall> Ok! transmission-gtk uses negligible cpu with clearlooks theme (and visual effects "none" and no subpixel font smoothing (laptop)).
19:00:23 < cwall> Re-enabled "visual effect" and font smoothing with no slowdown; going from clearlooks to "ambiance" made transmission cpu rocket up. The cpu usage with paused torrents occurs right away.
19:00:39 < cwall> right, well, certainly i have a workaround. gtk, eh. :)

[veldt (veldt)]

cwall's new username is veldt. I'm thinking this might be a bug for light-themes instead, considering that the ambiance theme triggers it.

In potentially-unrelated bug #663848 in light-themes, there is mention:

> https://trac.transmissionbt.com/browser/trunk/gtk/torrent-cell-renderer.c is the Transmission code that does the renderering for these screenshots. As you can see, there are two GtkCellRendererTexts -- one for errors, and one for non-errors.

Looking at that and other code, I'm trying to find how a torrent is marked as paused and what routine in transmission finally delegates the rendering of such a torrent, so I can follow it a bit deeper (e.g. into gtk or cairo.) I'd be glad if someone could tell me.

On another tack, if there is any valgrind/strace/gdb/profiling that might help, I'll try to find the time to do so. (Hmm, I'd _love_ to find out exactly what path is leading to ~85% overhead courtesy of libcairo -- I haven't got the source to the ambiance theme yet.)

Other users with the high-CPU bug have different video chips, but just in case, mine (from Xorg.0.log) is:
Chipset: "ATI Radeon XPRESS 200M 5955 (PCIE)" (ChipID = 0x5955),
running compiz.

System is up-to-date ubuntu 10.10 maverick installed bare from maverick-beta, on an HP Pavilion zv6130us laptop, running transmission 2.11+9713~maverick1 nightly, behaving the same as versions back to 2.04-0ubuntu2.

How common is it for people to pause torrents? If it's common, and if ubuntu 10.10 maverick is in widespread use, we should be seeing lots of complaints (soon?) -- unless it's something about my system, like my video chip or chipset.

[Andrea Cimitan (cimi)]

which widget is causing the slowdown?

[Charles Kerr (charlesk)]

it appears to be one of the torrent cell renderers. transmission uses three of them: gtk_cell_renderer_text, gtk_cell_renderer_progress, and gtk_cell_renderer_pixbuf. My first semi-blind guess would be the progress renderer.

[veldt (veldt)]

It's the GtkTreeView widget. A "ghosted" display is rendered when the GtkCellRendererText/Pixbuf/Progress elements making up the display of a torrent cell have the "sensitive" property false. This occurs with torrents that are not in an error state and are paused.

That code is in transmission's gtk/torrent-cell-renderer.c, in render_compact() and render_full().

[Andrea Cimitan (cimi)]

could be the text. will invesigate

[Andrea Cimitan (cimi)]

"pango_cairo_layout_path (cr, layout)" call is slow. I don't know if that's a problem in cairo, or if I should not use it. I'm using it in murrine for high-quality text shadows

[veldt (veldt)]

(Just skimming, in http://library.gnome.org/devel/pango/stable/pango-Cairo-Rendering.html, in description of pango_cairo_create_layout (): "This function is the most convenient way to use Cairo with Pango, however it is slightly inefficient since it creates a separate PangoContext object for each layout. This might matter in an application that was laying out large amounts of text." The current bug does not involve large amounts of text, so that description does not apply or is inaccurate; or it may not apply to the current bug: I haven't yet checked pango/cairo in the murrine source.)

[veldt (veldt)]

More dianostics; might be completely normal:

Did cairo-trace --profile transmission-gtk.
Got these errors, which were exactly replicated on a following run of plain "transmission-gtk":

(transmission-gtk:5936): Gtk-CRITICAL **: IA__gtk_tree_selection_selected_foreach: assertion `GTK_IS_TREE_SELECTION (selection)' failed

(transmission-gtk:5936): Gtk-CRITICAL **: IA__gtk_tree_selection_selected_foreach: assertion `GTK_IS_TREE_SELECTION (selection)' failed

(transmission-gtk:5936): Gtk-CRITICAL **: IA__gtk_tree_selection_get_tree_view: assertion `GTK_IS_TREE_SELECTION (selection)' failed

(transmission-gtk:5936): Gtk-CRITICAL **: IA__gtk_tree_view_get_model: assertion `GTK_IS_TREE_VIEW (tree_view)' failed

(transmission-gtk:5936): Gtk-CRITICAL **: IA__gtk_tree_model_iter_n_children: assertion `GTK_IS_TREE_MODEL (tree_model)' failed

Then did lzma -cd transmission-gtk.5906.lzma > transmission-gtk.trace, and cairo-perf-trace transmission-gtk.trace:

[ # ] backend test min(s) median(s) stddev. count
[ 0] xcb transmission-gtk 13.842 13.959 0.65% 6/6
[ 0] xlib transmission-gtk 12.829 12.993 0.61% 6/6
[ # ] image: pixman 0.18.4
[ 0] image transmission-gtk 1.776 1.782 0.20% 5/6
[ # ] image16: pixman 0.18.4
[ 0] image16 transmission-gtk 1.746 1.755 0.32% 6/6

.. was hoping to get GL backend tests, but that's all I've got for now ..

[Andrea Cimitan (cimi)]

I am not so practice of these tests, what do you suggest?

[veldt (veldt)]

I would like a complete trace of a run of transmission-gtk that would show whether libcairo is spinning its wheels, or rather some other code is banging on libcairo, because it looks like cairo's the CPU-consumer.

pango_cairo_create_layout() may be more inefficient than in its description; a documentation bug? If so, don't use it here.

If you use that method for text shadows, a performance hit might only be noticeable in long-term-shadowing, like paused transmission torrents, as compared to temporary actions like menu dropdowns (just guessing) where a performance hit would go unnoticed. But if so (if pango/cairo layout is the slowdown), murrine, or, transmission will have to just "go italic" (I think you can think of a dozen better options :) -- or a special rule for transmission -- until such time as pango/cairo speeds up this path.

[Andrea Cimitan (cimi)]

murrine is just using:

  pango_cairo_layout_path (cr, layout);
  murrine_set_color_rgba (cr, &temp, 0.5);
  cairo_stroke (cr);

to draw the layout.
pango_cairo_layout_path (cr, layout);
is slow, calling pango_cairo_show_layout (cr, layout) completely fixes the issue, but then will break text using <span ...> whatever

[veldt (veldt)]

Does <span ..> define user-responsive elements? That has to be quick.

We are talking *slow* -- whatever is happening is gobbling 20% of 2000 MHz, or 400 M per sec, on my system.

On a lighter note, the assertion failures mentioned above are not consistent, happening perhaps 15% of the time, no failures otherwise.

[Andrea Cimitan (cimi)]

it is used by the app developer to change the color of the text (for example the dialog appearing when you press the power button on your laptop. with suspend, hibernate etc etc)

drawing the cairo path seems to eat the cpu, don't know if that's a cairo or a pango bug. murrine is just requesting it, not sure if there's another way to do the same thingcomunque

[Andrea Cimitan (cimi)]

just thing not thingcomunque (middle click pasting) :)

[veldt (veldt)]

More diagnostics: this is the output of "perf top" during a transmission run with paused torrents. The CPU usage reported by regular "top" fluctuates between 24% and 48% for the transmission-gtk process. The attachment shows _cairo_bentley_ottmann_tessellate_polygon() using the most: 50.5% (of the non-idle CPU time, I suppose.)

[veldt (veldt)]

Hmm, pango might be involved in this too (rendering lots of curvy text via cairo? guessing) This response from cairo on our current topic (mentioning pango_cairo_layout_path(), and the high CPU usage in transmission-gtk being in _cairo_bentley_ottmann_tessellate_polygon()) suggests rendering to a temporary surface as a workaround, thanks M Joonas Pihlaja:

https://bugs.freedesktop.org/show_bug.cgi?id=31589#c1

-- excerpt --
From the code path snippet provided, I expect what's happening is that the
outline path involves lots of curves, and unfortunately those cannot be
fastpathed to bypass the stroker's call to tessellate the stroked outline when
using the xlib surface.

In any case, the image backend uses a different rasterisation method in 1.10 so
the regression doesn't occur as much, so a possible workaround might be to use
a temporary image surface to render the strokes.
-- end excerpt --

The cairo-perf-trace at the end of https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/655024/comments/31 seems to confirm that. It looks like rendering to "image" rather than directly to xlib or xcb is about 7.62 times faster.

[veldt (veldt)]

Some more suggestions on a possible workaround, from the cairo bugzilla:

https://bugs.freedesktop.org/show_bug.cgi?id=31589#c3

-- excerpt --
If you want ghosted text rendered at 0.5 alpha, then just render the text at 0.5 alpha. This avoids all use of the stroker. :) There are likely other methods to get shadows or ghosted text suitable for you, not involving the stroker, so if using a temporary image surface isn't a viable option, then perhaps investigating those in the context of your app might be a way forward? Please drop by the #cairo irc channel on freenode or post to the cairo-l mailing list if feel like it.
-- end excerpt --

[Andrea Cimitan (cimi)]

I did not undertand what he is proposing with the first line...

[veldt (veldt)]

It looks like if you could have the cairo stroker use a temporary surface in this case, it would be much faster than direct rendering. The major CPU in this bug is spent in a "tesselating" function. Long story short, it looks like there are ways to avoid activating that function. The function is used when cairo renders to xlib or xcb, which I imagine is what murrine does now. This quote indicates that drawing to a "temporary surface" and copying from there should help a lot (future cairo optimizations may fix this):

.. (T)he rasterization method (new in 1.10) used by the image backend can deal with self-intersecting
polygons just fine, so there's no need for tessellating the outline polygon.

.. from cairo bugzilla on this issue at https://bugs.freedesktop.org/show_bug.cgi?id=31589#c3

I assume that rendering to a temporary surface will use this faster "image" backend (6 or 7 times faster in transmission-gtk+murrine, according to cairo profiling tools I've used.)

Before I dig deeper, can you tell me something about this code:

  pango_cairo_layout_path (cr, layout);
  murrine_set_color_rgba (cr, &temp, 0.5);
  cairo_stroke (cr);

.. you mentioned "pango_cairo_layout_path (cr, layout);
is slow". Is that definite, or could it be cairo_stroke(cr);

Thanks!

[Andrea Cimitan (cimi)]

IIRC, when I tried using an image surface, the quality was poor... that's why I was using this.
whatever is cairo_stroke or the layout path, the problem seems to be in the second one, cause if I user show_layout instead layout_path + stroke is fast again. (but it exposes the bug of rendering text inside <span> tag)

[veldt (veldt)]

My current theory is that the cairo routines murrine uses to draw shadowed text have become slower when using recent versions of cairo, such as version 1.10.0 in ubuntu 10.10 maverick. Probably not noticeable normally, except that with transmission-gtk running on compiz, this text rendering may be happening much more often than necessary, causing a dramatic slowdown in that app.

If this is correct, there are two solutions, or three, if you count cairo speeding up:

1) Reduce unnecessary re-rendering in transmission-gtk -- an issue for the app, gtk+, and/or the window manager compiz. This would likely speed up execution the most.

2) Speed up murrine's rendering of shadowed text.

3) See cairo bug.

Details for all three are linked here. I would like it if for point 1, someone could confirm or tell me how to check whether paused torrent cells in transmission-gtk are being rendered repeatedly.

Details/hints.

1) From track of this bug in cairo bugzilla (now redirected to an earlier bug):
https://bugs.freedesktop.org/show_bug.cgi?id=31589#c5
As to already-rendered items continuing to consume CPU (after a surface flush), the only reason why that would happen is if the application itself is actually rerendering the items, say due to a new expose event from the window manager. There are currently no secret elves in cairo to burn your CPU just because they can when you're not looking. :)

2) Advice from M Joonas Pihlaja, ending with links to complete code and a nice set of rendered shadows:
I looked at the cairo-trace you provided in some detail, and it seems that the slow bit is indeed using stroking to "shadow" text. A faster and more accurate method to create shadowed text is to render the content-to-shadow to a temporary surface first and then paint that to the target surface twice at slightly different offsets, something like this:

/* Render to a temporary surface (similar to your target surface). */
cairo_push_group(cr);

{
  /* render your text here with pango for example. */
}

text_pattern = cairo_pop_group(cr);

/* Drop the shadow. */
cairo_save(cr);

{
  double shadow_alpha = 0.5;
  double shadow_offset = 2; /* note: keep this an integer */
  cairo_translate(cr, shadow_offset, shadow_offset);
  cairo_set_source_rgba(0,0,0,shadow_alpha);
  cairo_mask(cr, text_pattern);
}

cairo_restore(cr);

/* Paint the text on top of the shadow. */
cairo_set_source(cr, text_pattern);
cairo_paint(cr);
cairo_pattern_destroy(text_pattern);

The technique is illustrated with code that's actually been run here:

http://people.freedesktop.org/~joonas/shadow.c
http://people.freedesktop.org/~joonas/out-shadow.png

3) This cairo bug is entitled "Performance regression in synthetic micro-benchmark [due to global stroke tessellation] ":
https://bugs.freedesktop.org/show_bug.cgi?id=28067

[Andrea Cimitan (cimi)]

tried that code in murrine, low quality shadows compared to the one we have now :(

cairo_pattern_t * text_pattern;

/* Render to a temporary surface (similar to your target surface). */
cairo_push_group(cr);

cairo_translate (cr, x, y);
murrine_set_color_rgb (cr, use_text ? &colors->text[state_type] : &colors->fg[state_type]);
pango_cairo_show_layout (cr, layout);

text_pattern = cairo_pop_group(cr);

/* Drop the shadow. */
cairo_save(cr);

cairo_translate (cr, xos, yos);
murrine_set_color_rgba (cr, &temp, 0.5);
cairo_mask(cr, text_pattern);

cairo_restore(cr);

/* Paint the text on top of the shadow. */
cairo_set_source(cr, text_pattern);
cairo_paint(cr);
cairo_pattern_destroy(text_pattern);
cairo_destroy (cr);

[veldt (veldt)]

Hi Andrea! The latest major release of cairo is version 1.10.0; it is a recent release, 71 days old; have you grabbed it yet? It would improve the quality of your rendering test above. If you are using cairo 1.10.0 in the above test, any poor quality might be a cairo bug -- screenshots of your test above would be very helpful.

[Andrea Cimitan (cimi)]

Yes,
will take a screenshot tomorrow
--
Andrea Cimitan - http://www.cimitan.com
Software Engineer | Desktop Experience Team
Product Strategy | Canonical Ltd

[veldt (veldt)]

I did tests in transmission's gtk/torrent-cell-renderer.c on the function torrent_cell_renderer_render(), and found that it ran 3.21 times a second with 35 paused torrents and 3.43 times per second with all unpaused. My speculation of excessive redraws is withdrawn, in the case of the transmission-gtk app.

[Eden (edencaldas)]

Just wanted to say I was having the same issue. I installed transmission-qt and while using it my cpu doesn't get so much load and transmission interface doesn't lag.

[veldt (veldt)]

warning, may contain wishes :)

I've done more tests with transmission-gtk and all torrents paused. The content of the transmission-gtk window is visually static, with no pixels changing. No other window partially obscures it and the mouse pointer is not moving; there should be no cause to redraw anything. torrent_cell_renderer_render() does a render_compact/_full() 3.31 times/sec. Not much, but these are inactive, unchanging things and do not need continual rerendering. Since the rerendering is slow, it becomes not merely "unnecessary", but "crippling". This would be a gtk+ or compiz window-manager issue, I think, although it may also be perfectionism; on fast modern hardware with complex gui's, can one really blame a window manager or gui-toolkit for updating something only every 1/3 of a second? Sigh.

Having said that, if I swish the mouse pointer around on top of the paused torrents (not clicking), render_compact/_full() is called twice as often -- 6.79 times/sec, and my cpu usage doubles.

I can understand the window manager saying, "Look out, there is user activity", but with modern GUI's, why bother redrawing the stuff under the mouse if there is no "glowing" of items the mouse comes near, nor "hover" reactions of any kind?

I guess that's two wishes: don't redraw *even a little bit* if it's not necessary, and, don't repaint under the mouse if you're not reacting to it.

[veldt (veldt)]

I switched window managers from compiz to metacity (both are included in ubuntu and switching appearance preferences to "None" changes the window manager, observing the process list) and it's still slow. metacity is a GTK+ window manager, and now I'll be testing the kde one.

[Eden (edencaldas)]

Yesterday I got high cpu usage with deluge-gtk as well. It was like 50% cpu usage with only one torrent downloading from a few peers. I switched to transmissioncli and it was like 1% cpu usage.

[veldt (veldt)]

I installed "kubuntu-desktop" to try the kwin window-manager. transmission-gtk ran fine, no slowdown. I went to kde's "System Settings" -- "Application Appearance" -- "Style", and changed "Widget style" to "GTK+ Style". (Under the "Fine Tuning" tab, I also changed "Graphical effects" to "High display resolution and Very High CPU". Then (still under "Application Appearance") in "GTK+ Appearance" I chose Ambiance under "Widget style". The slowdown with paused torrents returned.

[Dmitry Andreychuk (and-dmitry)]

I can confirm that changing theme helps. Changed from Radiance to Clearlooks: no lags when scrolling and much lower cpu usage.

[Charles Kerr (charlesk)]

I've been getting reports about this issue in the Transmission forums, as well. It would be nice if it could get fixed in time for 11.04.

Also if there's anything I can do downstream in Transmission to ameliorate this, please let me know.

[Virgil Brummond (uraharakisuke153)]

I can confirm this. Transmission QT uses less than 1% of my cpu while running and is very very smooth.
************
The GTK version uses over 13 and generally is very slow to scroll, switching to the theme "Clearlooks" has resolved this.

[veldt (veldt)]

This is hardly a patch -- it is against the latest transmission nightly, and only swaps out rendering "sensitive". With it, pausing torrents reduces (!) CPU, by more than 50 percent.

[veldt (veldt)]

Hi Andrea! This is about rendering cairo shadowed text to a temporary
image surface that we talked about a few months ago. cairo's M Joonas
Pihlaja still wants a screenshot of the test you did in this post:
https://bugs.launchpad.net/libcairo/+bug/655024/comments/45

I'm hardly a GUI expert, so my e-mail to you in November may be meaningless:

--- begin excerpt ---
You can hold off on that screenshot if you want. But I'd rather you
didn't. I've determined that gtk+ or compiz or the darn app is calling
for redisplay at least once every 0.3 seconds. Totally unnecessary, I'd
say, but who am I to judge?

Granted, it's only 3 torrents and their cells per second, out of 35. But
it should be 0. If they're paused and non-dynamic.

If there is no alternative, I will talk to canonical about linking an
earlier cairo to transmission-gtk. Your theme should be fine. As it
already is
--- end ---

I retrofitted libcairo 1.8 onto my system and that did not fix the
problem -- CPU usage went up more than 400% displaying paused torrents
in transmission-gtk. As you may recall, these are rendered with the gtk
property "sensitive" = FALSE, which murrine draws shadowed. So going to
an earlier libcairo didn't help.

This dramatic slowdown only seems to have started with October's ubuntu
Maverick, despite the fact that I believe your theme has been the
default since April's Lucid.

In
https://bugs.launchpad.net/libcairo/+bug/655024/comments/55
one of the gui developers of transmission-gtk expressed interest in
getting his app working nicely in the next ubuntu release. I posted a
silly mini-patch in comment 57 which turns off the slow non-sensitive
rendering, but since I am not a GUI developer, I just put in an xpad
offset for paused elements instead of non-sensitive, and this makes them
"shimmer" when you mouse over them. It's not a fix, but it eliminates
the slowdown as a "proof of concept." Is there a way you can make an
exception in your theme for "transmission-gtk" to render non-sensitive
elements bold and lighter? That would look similar to the shadowed
rendering I see now, and I hope it would be faster.

As I said, there is always a chance the transmission-gtk guy will look
at some other way than non-sensitive to render paused elements, but
please let me know how you feel about all this.

Thanks for your work!

- veldt

[Charles Kerr (charlesk)]

notes for upstream commit r11740:

reduce unnecessary re-rendering in the main window

The main window called gtk_tree_model_filter_refilter() once per second to refresh the torrent list's filtering. This is not an efficient approach: gtk_tree_model_filter_refilter() emits a "row changed" event for every row, causing unnecessary re-rendering.

I've removed the call to gtk_tree_model_filter_refilter() and expanded the model to include all the fields necessary for filtering. That way we only fire "row changed" events for rows that actually change.

By reducing the number of renders in steady state, this might ameliorate https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/655024

However it will *not* help the related "CPU spikes to 100% on scrolling" ticket at https://trac.transmissionbt.com/ticket/3887 because rendering paused torrents is still exceptionally expensive in the murrine theme.

[Charles Kerr (charlesk)]

> Granted, it's only 3 torrents and their cells per second, out of 35.
> But it should be 0. If they're paused and non-dynamic.

The list is sorted, which causes rerendering when the list resorts even if the torrent is unchanged.

> If there is no alternative, I will talk to canonical about linking an earlier cairo to transmission-gtk.

I'm not sure this will solve anything. Veldt, Rolcol, and Virgil have all reported the problem goes away when changing to a non-murrine theme, which afaik does not involve a different version of cairo.

I'm working on ways to reduce the number of refreshes triggered by the application code, but since (1) this doesn't happen in any other theme, and (2) the CPU still spikes to 100% on scrolling no matter how many periodic refreshes the application code triggers, the root of the problem still appears to be in the murrine theme.

[Charles Kerr (charlesk)]

Attached is a patch that we can use in Transmission if text shadows don't get resolved in Murrine and/or Cairo in time for 11.04.

The patch avoids use of GtkCellRendererText's "sensitive" property, and instead renders paused torrents' text using the widget's style's color for insensitive text. This approach honors the theme's "insensitive" color setting and uses it to draw insensitive text with no etching or shadowing.

Veldt, would you be able to compare CPU loads with and without this patch using the default Ubuntu theme(s)?

This patch is intended as a "Plan B" for 11.04 -- the better option is still to solve the theme's text shadow issue.

[hectoralex (u2alex)]

Hey guys,Count me in, I'm having the same problem here... went from 10.04 to 10.10 and experiencing the same problems of Transmission UI running like molases(extremely slow). I am also having the system freezing when Transmission is running after a day or two on a bittorrent dedicated computer.

[veldt (veldt)]

"top", with updates every 3 seconds. Mouse in another window. 64 torrents, 7.8 fit onscreen at once, non-"Compact View", CPU locked to fullspeed (Athlon 64 2 GHz), "new" = r11752, "old" = "new" with torrent-cell-renderer patch (11747) reversed.

CPU usage, 300 second test:
new and old, all onscreen torrents unpaused: 1.0 - 3.3
new, all onscreen torrents paused: 0.7 - 3.3
old, all onscreen torrents paused: 28.2 - 53.4

[Charles Kerr (charlesk)]

Thanks veldt :)

[veldt (veldt)]

#! Solid, jordan.

[Krzysztof Klimonda (kklimonda)]

please, don't change the bug status without a reason. The fix has not yet been released in Ubuntu - I've pushed patch to the lp:ubuntu/transmission branch, but has not yet pushed the package, as I have few more patches to prepare first.

[Launchpad Janitor (janitor)]

This bug was fixed in the package transmission - 2.13-0ubuntu5

---------------
transmission (2.13-0ubuntu5) natty; urgency=low

  * debian/patches/0105-murrine_high_cpu_workaround.patch: (LP: #655024)
    - Workaround the issue found in Murrine that causes high CPU usage
      in Transmission.
  * debian/patches/0106-avoid_descriptor_leak.patch (LP: #661947)
    - Avoid descriptor leakage that caused "Too many open files" error.
  * debian/patches/0107-handle_unsorted_blocklist_rules.patch
    - Handle overlapping/unsorted blocklist rules.
  * debian/patches/0104-add-scheme-handler.patch
    - update patch to remove attribute passed to transmission-gtk in Exec
 -- Krzysztof Klimonda <email address hidden> Wed, 16 Mar 2011 05:48:44 +0100

[Andrea Cimitan (cimi)]

With the latest murrine from git, I've added a workaround for that...

[Taylor "Ripps" LeMasurier-Wren (ripps818)]

Sorry about the spam, somebody hacked my gmail account week ago. Does anybody know how to delete posts?