Way to reproduce:
This is caused by any dynamic statistic that takes a window > step.
This produces intervals that overlap, and that is why these strange graphics appear.
For example 9.66 to 10.66 then 10.16 to 11.16
Maybe we can add validation so the user can't input a step lower than the window.
No, this is intentional: this is how sliding windows work, and they are very useful. An acceptable solution is to rebuild intervals so that they are reduced. In your example, 9.66 to 10.16 then 10.16 to 11.16. Another example:
Computed intervals are on 0 to 2, 1 to 3, 2 to 4, 3 to 5. Then they are rebuilt as:
0 to 1, 1 to 2, 2 to 3, 3 to 4, 4 to 5.
But this is a bad example, we should consider the dynamic metrics as follows. Each value is computed from a starting point to a starting point + size of the window. Then we add the tick to the starting point, and compute a new value. So the sparkline should draw this value at each starting point until the new starting point.
Is it clearer? You may refer to the image embedded in Gephi dynamic metrics, icon help (i).
Eduardo, can you provide guidance to help me fix this bug? However if it touches to Gephi architecture I must let you do it.
This only needs a simple code addition to TimelineControllerImpl (starting at line 310) in Desktop Timeline module.
My idea is:
Build levels from intervals start up to intervals end, unless next interval start is before current interval end. In that case, current level only goes from current interval start to next interval start, and so on.
Here is the necessary code if that matches your idea https://gist.github.com/2705818 Tested it seems to work fine.
Fix issue #615
So simple once you know the answer :) Thanks @eduramiba!