Version: 1.1.0_beta1 (using KDE 3.4.0, compiled sources) Compiler: gcc version 3.3.5 OS: Linux (i686) release 2.6.9 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.
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) {