Behavior of jumpTo

[Kevin Rushforth]

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