Disclaimer: I know nothing of GTK or Cairo. First up, the source:
http://git.gnome.org/browse/gnome-system-monitor/tree/src/load-graph.cpp This comment: // FIXME: // on configure, g->frames_per_unit = g->draw_width/(LoadGraph::NUM_POINTS); // knock FRAMES down to 5 until cairo gets faster This value is set to 10, not 5. I haven't profiled it, but that comment would suggest cairo_curve_to is the problem. The canvas appears to be stateless, redrawing everything every frame. The obvious solution is to implement a cache for the graph rather than blaming Cairo for the speed. Cairo must have ways to manipulate graphics buffers. Keep two around as part of the load graph state, one for the background and one for the graph. Draw in a cyclic manor each frame like so: 1) Work out a width based on the last drawn position and the current one. Blank it out from left to right, wrap around if necessary. 2) Draw the line segments from the last drawn position to the current "cursor position" 3) Stamp down the graph background onto the canvas 4) Draw the line segments in two halves, giving the illusion of a scrolling buffer This will remove 99.9% of the smooth line drawing calls, it will cost a small memory cache, but that's the reason we have RAM anyway. Workarounds: a) Do as the comment says, set frames_per_unit to 10 instead of 5, this will draw less line segments. This will call g_timeout_add with a larger interval. b) Set the default /apps/procman/graph_update_interval to something higher, say 2000 or 5000. This would just suck. c) Draw jagged lines instead of smooth ones, this may be faster. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/93847 Title: Excessive CPU usage by Gnome System Monitor -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
