ActivityMonitor shows graphics at the 0 position for positions close to the current one.

[bga]

Besides what is described in the title of the bug, it also shows the current numeric values as 0 although it *IS* obviously correctly reading the data as in positions after a few seconds in the history it does show correct past values. The screemshot will probably make the problem obvious.

[bga]

ActivityMonitor bug.

[axeld]

Yes, that's a known problem; it happens because of the way the current value is computed - since the data source retrieval happens in the window thread, it can easily lose a value (for example when doing a screenshot). Even if it would not run in the window thread anymore (which would make this problem a lot less likely), it might still lose a value under heavy load.

[bga]

I don't quite understand what you mean (although I did not look at the code yet so this could be just it). I guess you are using a Message Runner or Pulse to update the data. Wouldn't it be better if you then retrieved the data when updating the values and kept track of the delta between the time of the last update and the current time? This way the graphic may not be accurate for small intervals but at least it would be a better representation than dropping the value to 0. :)

Also, do you actually force the numeric values to be displayed to 0? Because if they just retrieve the information from the system, I don't see how come they can get a 0 value no matter if the CPU is pegged or not.

[axeld]

Fixed in hrev26409.

[bga]

Maybe it is not exactly the same problem but the memory graphs still look wrong. They are stuck at the 0 position (although currently there is 378.9 Mb used with 190.6 mb of cached memory. The graphic didn´t change even once since boot. staying flat at position 0.

So, reopening.

[anevilyak]

Are you sure you rebuilt your stuff properly? It works fine over here, watching the cache / mem graphs steadily increase during an SVN checkout. How much RAM is on the box you're trying this with? mine's 1GB. Also, is the mem graph the only one you see issues with?

[bga]

New screen capture.

[bga]

Yes, I am.

Tried at home with a Intel Core 2 Quad Extreme and 4 Gb of memory (around 3.5 detected by Haiku).

Tried again here at work under VMWare with a full build (erased the generated directory). Configured with 2 Gb of RAM and one virtual CPU. Started a svn checkou and with around 20% of the memory used, the graph was still at position 0 (see new screen capture).

I only have this problem with the memory monitors. Others work but I just noticed that in the CPU monitor, the graph keeps changing. From one redraw to another, peaks and valleys disappear and reappear again, which is kinda odd.

[bga]

So if I change the memory amount in VMWare to 1 Gb, it works as expected. I guess there is a signed int overflow somewhere.

[axeld]

That's a different bug that should have always appeared with more than 2 GB of memory. Anyway it's fixed in hrev26430.