[Kst] [Bug 104765] skipping frames in live data causes mysterious
'retrace line' to appear randomly
Andrew Walker
arwalker at sumusltd.com
Fri May 13 01:58:45 CEST 2005
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.kde.org/show_bug.cgi?id=104765
------- Additional Comments From arwalker sumusltd com 2005-05-13 01:58 -------
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?
More information about the Kst
mailing list