Just to confirm (unless my hardware is a corner case), this bug seems
fixed in freedesktop (freedesktop.org bugzilla #22576); will it be
incorporated in ubuntu, ideally 13.04?
My hardware seems close the original posters' -- legacy radeon -- I'm
using r300 but they seem to be on r200, but the
#! Solid, jordan.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/655024
Title:
Using higher cpu usage
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
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
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
--
You received this bug notification
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.
** Attachment added: patch__torrent-cell-renderer.c
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
** Changed in: libcairo
Remote watch: freedesktop.org Bugzilla #31589 = freedesktop.org Bugzilla
#28067
--
Using higher cpu usage
https://bugs.launchpad.net/bugs/655024
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
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.
--
Using higher cpu
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
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
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
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
** Bug watch added: GNOME Bug Tracker #634805
https://bugzilla.gnome.org/show_bug.cgi?id=634805
** Also affects: transmission via
https://bugzilla.gnome.org/show_bug.cgi?id=634805
Importance: Unknown
Status: Unknown
** Project changed: transmission = pango
--
Using higher cpu
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
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
** Bug watch added: GNOME Bug Tracker #634881
https://bugzilla.gnome.org/show_bug.cgi?id=634881
** Also affects: transmission via
https://bugzilla.gnome.org/show_bug.cgi?id=634881
Importance: Unknown
Status: Unknown
** Project changed: transmission = gtk
--
Using higher cpu
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
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
** Bug watch added: freedesktop.org Bugzilla #31589
http://bugs.freedesktop.org/show_bug.cgi?id=31589
** Also affects: transmission via
http://bugs.freedesktop.org/show_bug.cgi?id=31589
Importance: Unknown
Status: Unknown
** Project changed: transmission = cairo
** Project
** Bug watch added: freedesktop.org Bugzilla #31589
http://bugs.freedesktop.org/show_bug.cgi?id=31589
** Also affects: libcairo via
http://bugs.freedesktop.org/show_bug.cgi?id=31589
Importance: Unknown
Status: Unknown
--
excessive cpu usage with murrine themes only, when
(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
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
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
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
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
** Bug watch added: GNOME Bug Tracker #634308
https://bugzilla.gnome.org/show_bug.cgi?id=634308
** Also affects: transmission via
https://bugzilla.gnome.org/show_bug.cgi?id=634308
Importance: Unknown
Status: Unknown
--
Using higher cpu usage
If you have any torrents that are paused, and if you are using default
the ubuntu 10.10 theme, Ambiance, this may be a duplicate of
https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/655024
..which affects me.
If you have paused torrents, could you see if your problem is solved by
going
** Project changed: transmission = murrine
--
Using higher cpu usage
https://bugs.launchpad.net/bugs/655024
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Public bug reported:
Binary package hint: gtk2-engines-murrine
Expected behaviour: pausing torrents in transmission-gtk should not increase
CPU usage
Observed behaviour: CPU usage increases instantly, more for each torrent paused
Latest test shows 1% extra CPU per paused torrent, which adds up
** Bug watch added: GNOME Bug Tracker #634308
https://bugzilla.gnome.org/show_bug.cgi?id=634308
** Also affects: murrine via
https://bugzilla.gnome.org/show_bug.cgi?id=634308
Importance: Unknown
Status: Unknown
--
excessive cpu usage with murrine themes only, when
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
31 matches
Mail list logo
