This bug has been identified by a few people with gnome system monitor in 2.24, it is concerned with the graph taking up too much CPU time. My testing has been done with the intel driver, the ati fglrx driver (haven’t tried RadeonHD yet as it doesn’t work well on my iMac) and on the nvidia driver (from when I was running a computer with a nvidia chip), while testing I have never been able to reproduce this bug, I have of course added tweaks here and there to the original design to improve things but still I cannot replicate this issue.
Now I no longer have a nvidia machine, mores the pity, apple use these Radeon 2600HD chips in the iMacs so I must endure ati until the RadeonHD driver is finished, continued testing on the intel driver works fine and on the fglrx driver some bugs are present in many apps where cairo is utilised (weird hue differences) but never because of the actual cairo code…
So what is it doing when the issue appears? I believe it is related to XXA rendering as I use EXA when available, EXA appears to work far more effectively but having said that XXA never produced a problem for me either, some say that the entire surface is being copied one pixel at a time when I paint it onto the scene, this would indeed be the cause but surely the drivers shouldn’t do that! From my reviewing of the system monitor code I can’t see anything that would be needless, and therefore provide a performance boost. There are some small niggles in the implementation however it wouldn’t be so difficult to remove them and even then the niggles are purely bling related (on configure redrawing the graph line buffer for instance).
I considered setting the clipping area around the vertical maximum/minimum points of the displayed graph line as per Jason Clinton’s recent post but as I’m not really doing any more drawing in the scene I don’t see why this would help in this case.
If anyone has any ideas, patches, rants or related issues then please put comments into the bug or on my blog where appropriate. **long stare across the gnome planet toward cworth**
#1 by blah on April 10th, 2008
RadeonHD is being phased out. Use the normal radeon driver. It supports the new cards, too. And is the driver that is being actively worked on.
#2 by ulrik on April 10th, 2008
I noticed this a soon as I upgraded, the first thought was exactly that.. Very pretty graphs but totally pointless.
If you use a tool to measure something, would it be ok if it disturbed its subject this much? It’s basically measuring itself..
Something really has to be done and the pretty graphs have to taste the axe because more than 1-3 % absolute error is not ok by me..
#3 by JGJones on April 10th, 2008
I get this bug myself too – here’s a screenshot for your viewing pleasure:
http://gwallgofi.com/sysmon.jpg
It’s on a Intel Core 2 Duo 2.2GHz system with NVidia 8600 graphics and 2GB of RAM…so system grunt isn’t an issue here(!)
I simply just don’t touch the graphics area when using System Monitor (although I actually use htop mostly)
#4 by danguy on April 10th, 2008
I have exactly this bug on my new 2.22.1 installation (Gentoo, ThinkPad T43, Radeon X300 /w fglrx, dual-screen). The graphs work fine when the window is scaled down, but at the normal size it takes 100% CPU and there is about 1 frame every 5 seconds; the whole System Monitor is then unresponsive.
#5 by Kalle Vahlman on April 11th, 2008
I suppose the quoted clipping issue (or, in more general, the alpha blending) is the major cause of it.
If you are drawing and *not* hitting exactly on the pixel grid, the resulting edges will need to be blended. If the destination surface does not support accelerated operations with alpha, it means that the destination image needs to be fetched from the video memory (SLOW), composited in software and then pushed back.
This holds true for rectangular integer-positioned fills too, for the reason described in http://cairographics.org/FAQ/#sharp_lines
If you want somewhat consistent performance regardless of bad drivers, do *all* your compositing in software (ie. construct the whole graph in cairo image surfaces) and just blit the result to the server side surface. This sucks for network clients though as the clientserver traffic is increased.
Unfortunately the “somewhat consistent” part implies that it can only be as fast as your blit from the client side, and doesn’t get faster even if your graphics hardware could do all the work instead of your CPU.
So in other words: IMO there isn’t a full satisfactory solution for this that doesn’t involve fixing/providing good drivers to graphics hardware. Fortunately that situation (slowly) changing for the better.
#6 by SZERVÃC Attila on May 29th, 2008
3D RadeonHD Driver!
http://www.phoronix.com/scan.php?page=article&item=ati_r500_3d&num=1
——————————————
SZERVÃC Attila