GNOME Bugzilla – Bug 550708
Load graphs should compute damage regions and use queue_draw_area
Last modified: 2013-08-02 06:25:28 UTC
In load_graph_draw, gtk_widget_queue_draw is called which in turn will trigger an expose event on the widget with a single damage rectangle consisting of the entire widget allocation. If damage can be computed ahead of time based on the plot data, it could be beneficial to call gtk_widget_queue_draw_area instead. The expose handler should then be updated to iterate over the damage rectangles, clip the cairo context to those regions, and render only what is damaged. For instance, if there's been no CPU spike above 10%, then there's no reason to render the 100%-10% region of the graph on each iteration. Smartly subdividing the plot into damage regions can help a /lot/.
I would really eliminate the scroll. It's just not worth the effort, IMO. Instead an oscilloscope-like view, just like the one it had before if I remember it right, is good enough: plotting starts from the left and continues towards the right border and when it reaches it the box is cleared and plotting starts over from left again.
As already explained, you can quite easily improve the scrolling performance by using gdk_window_scroll() whenever new data points need to be rendered. This will copy the existing content of the window using a screen-to-screen blit and invalidate only the area that actually needs to be drawn because it has not been drawn before. Then you just need to make sure that the expose event handler does only redraw the invalidated area. I would only consider other optimizations if this approach shows not to be sufficient.
@Enver ALTIN: If you do this, the graph will lose most of it's usefulness because whenever you really need to see a longer load history, it will just have started from scratch and only show the last 2 seconds :)
[Adding missing "QA Contact" entry so system monitor bug report changes can still be watched via the "Users to watch" list on https://bugzilla.gnome.org/userprefs.cgi?tab=email when the assignee is changed to an individual.]
As uber-graph is a smarter graphing library, integrating that would solve this too, so I am marking this as a duplicate of the uber-graph ticket. Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 636343 ***