4. When setting an effect's local time to its duration, currently it stays at the "final state". e.g. for the following effect:
  const effect = new KeyframeEffect(target,
    [
     { opacity: 1 },
     { opacity: 0 }
    ], {
      duration: 1000,
    }
  );
setting effect.localTime = 1000 upon animating makes the target 'opacity: 0'.
However, if the effect has specified an iteration count, e.g. iterations : 2, setting effect.localTime = 1000 makes the target 'opacity: 1' again as the second iteration starts.
It doesn't look consistent to me. Maybe it's a bug? Anyway we should spec this behavior as well.

I am trying to understand this a bit better.

The AnimationWorklet should not particularly need to spec the before/active/after behaviors itself. The phase is determined by local time value of the effect which is controlled WorkletAnimation.

Effectively, worklet animation is allowed toset the local time of its effect such that it puts is in before/active/after phase. Consider the following example:

  const effect = new KeyframeEffect(target,
    [
     { opacity: 1 },
     { opacity: 0 }
    ], {
      duration: 1000,
      delay: 500,
    }
  );

Give this I think the following is the expected behavior:

1)  effect.localTime = 0;    // effect is in before phase, so output is determined by fill-mode backwards and the start value of the effect
2)  effect.localTime = 800;  // effect is in active phase, so output is determined by effect interpolation
3)  effect.localTime = 1800; // effect is in after phase, so output is is determined by fill-mode forwards and the end value of the effect

I understand that cc is doing trimming and ignoring the fill behavior but I have to look closer into it to see how it is organized so that cc trimming behavior match the above.
If I recall for regular animations
 a) once animation is finished we cancel the composited animation so main animation controls the output in the after phase.
 b) composited animation does not tick before it is in active mode unless it has backwards fill mode. See [1]
 
So I think the combination of (a) and (b) ensures that cc trimming logic works the same as expected.



[1] https://cs.chromium.org/chromium/src/cc/animation/keyframe_model.cc?type=cs&sq=package:chromium&g=0&l=170

Right. Worklet animations don't have 'before' and 'after' phase as I mentioned in #1. Since they are 'active' the entire time, trimming it so that they are able to be ran sounds about right. But we need to spec this.

Another thing that needs to be specced is: what's the expected behavior if we set localTime to 1500 in the example per #2? The answer should be "opacity == 0" because we trim the local time to the range [start, end] for Worklet Animation. But in WebAnimation an active animation is within the range [start, end), i.e. 'end' is excluded. Since for slow path worklet animations we are reusing the regular animation logic, we kinda have this inconsistent behavior at the "end" point. We need to somehow spec this too.

> what's the expected behavior if we set localTime to 1500 in the example per #2?
 
I think we should match the web-animation model i.e., the effect duration is exclusive of its end point. In another word we should treat this as a bug in cc animation timing model since it is inconsistent with blink. I bet this bug also shows up for regular animation but we have perhaps not noticed it.

cc trimming is wrong. Fixing it via  issue 906675 . Close this one as there is nothing special to spec.