I agree. If jumpTo took a relative (delta) Duration then it would make
sense for it to take the direction of rate into account. Given that it
is an absolute position, the current behavior just seems wrong.
The spec says:
Jumps to a given position in this |Animation|
I would interpret that as being an absolute position, but clarifying
that with a spec change sounds like a good idea.
The only possible concern is compatibility. It's possible that some
applications have worked around this bug, but that doesn't seem
compelling enough to keep the buggy behavior.
-- Kevin
On 3/22/2020 8:08 PM, Nir Lisker wrote:
Hi,
As I'm continuing my work on the animations front, I came across an
ambiguous behavior of JumpTo. The specifications don't say anything about
it, but in FiniteClipEnvelop, if the rate is negative, it jumps to the
specified time *counted from the end*. This seems intentional because it's
checked explicitly:
pos = ticks % cycleTicks;
if (rate < 0) {
pos = cycleTicks - pos;
}
if ((pos == 0) && (ticks > 0)) {
pos = cycleTicks;
}
SingleLoopClipEnvelope does not behave this way. I submitted [1] to track
this. This also causes an issue with jumping when rate=0, however, there
are other issues with rate=0, for example [2], and it's hard to separate
them.
What should be the proper behavior of jumpTo with respect to the rate? I
think that they shouldn't be coupled: jumping should always be calculated
from the start. The application can always calculate (totalTime -
requiredTime) and send that to jumpTo.
- Nir
[1] https://bugs.openjdk.java.net/browse/JDK-8237973
[2] https://bugs.openjdk.java.net/browse/JDK-8237757
