Bug 104765

On Friday 29 April 2005 06:21, Matthew Truch wrote:
> When plotting live data, if you have skip frames set to some value greater
> than 1, a retrace line will randomly appear and disappear (with each
> update).  The 'retrace line' goes from the first point plotted to the last
> point plotted (looks like a lousy linear fit).
>
> Expected behavior: line doesn't appear.


  Does this have to do with a situation where the X vector has more samples 
than the Y vector at that instant?

> > When plotting live data, if you have skip frames set to some value greater
> > than 1, a retrace line will randomly appear and disappear (with each
> > update).  The 'retrace line' goes from the first point plotted to the last
> > point plotted (looks like a lousy linear fit).
> >
> > Expected behavior: line doesn't appear.
> 
> 
>   Does this have to do with a situation where the X vector has more samples 
> than the Y vector at that instant?


That's certainly possible, but would also be the case when not skipping
samples (but the problem doesn't occur when not skipping samples).  

I believe this problem is caused by a bug in KstRVector::doUpdate(...) in the following section of code:

  if (DoSkip) {
    // change new_f0 and new_nf so they both lie on skip boundaries
    //tmp_fn = ((new_f0 + new_nf)/Skip) * Skip - 1;
    tmp_fn = new_f0 + new_nf - 1;
    // new_f0 == 0 results in (new_f0 - 1)/Skip being -0.x which rounds the
    // wrong way on us.  Therefore new_f0 == 0 is a special case.
    new_f0 = new_f0 == 0 ? 0 : (((new_f0 - 1)/Skip) + 1) * Skip;
    new_nf = tmp_fn - new_f0 + 1;
  }

The problem is that if new_f0 is 0 then new_nf always remains unchanged, which is not the desired effect. It not only produces the reported bug, but also causes the entire vector to be reset at regular intervals. Unless I hear otherwise I'll check in the following:

  if (DoSkip) {
      if (new_f0 != 0) {
        new_f0 = (((new_f0-1)/Skip)+1)*Skip;
      }
      new_nf = (new_nf/Skip)*Skip;
  }

It's probably worth noting that there is another bug, in that if you specify a starting frame of 2 (for example) together with reading 1 sample per 5 frames (for example), you actually get a starting of frame 5. Not a major problem, but not what was asked for. This should also be simple to fix, but does change the current behaviour. Opinions?

SVN commit 415050 by arwalker:

Fix problem with skipping frames,
where starting frame is 0.

CCMAIL: 104765-done@bugs.kde.org

 M  +5 -7      trunk/extragear/graphics/kst/kst/kstrvector.cpp  


--- trunk/extragear/graphics/kst/kst/kstrvector.cpp #415049:415050
@@ -464,13 +464,11 @@
   }
 
   if (DoSkip) {
-    // change new_f0 and new_nf so they both lie on skip boundaries
-    //tmp_fn = ((new_f0 + new_nf)/Skip) * Skip - 1;
-    tmp_fn = new_f0 + new_nf - 1;
-    // new_f0 == 0 results in (new_f0 - 1)/Skip being -0.x which rounds the
-    // wrong way on us.  Therefore new_f0 == 0 is a special case.
-    new_f0 = new_f0 == 0 ? 0 : (((new_f0 - 1)/Skip) + 1) * Skip;
-    new_nf = tmp_fn - new_f0 + 1;
+      // change new_f0 and new_nf so they both lie on skip boundaries
+      if (new_f0 != 0) {
+        new_f0 = (((new_f0-1)/Skip)+1)*Skip;
+      }
+      new_nf = (new_nf/Skip)*Skip;
   }
 
   if (NF == new_nf && F0 == new_f0 && !force) {