Add time remap specs #56
Conversation
|
I think we might have talked about punting this to 1.1, but one of our internal 1.0 clients is relying on the feature. Since it's pretty straightforward to spec, and it's also supported with most players, it doesn't seem like stretch to add now - WDYT? |
|
I thought there were inconsistencies between implementations. Can we confirm it works properly on most players? |
docs/specs/layers.md
Outdated
| @@ -71,3 +71,76 @@ decrease it ("stretching" the layer timeline). | |||
| </script> | |||
| </lottie-playground> | |||
|
|
|||
| The `tm` property specifies a time remap function, which offers full control over the precomp | |||
There was a problem hiding this comment.
I'd create a new subsection for time remapping
There was a problem hiding this comment.
Done. Also added a subsection for time stretch.
Do you recall what the inconsistency was? I tested LottieWeb, LottieAndroid, and Skottie with this sample - they all seem to have good support. It also works fine in the LottieFiles app, although I'm not sure whether that's using your new player of LottieWeb still. Maybe you can double-check. |
docs/specs/layers.md
Outdated
| time expressed in seconds, and evaluates all animatable precomp properties based on the new | ||
| time value: | ||
|
|
||
| $$t\prime = TM(t) * FPS$$ |
There was a problem hiding this comment.
Is it allowed for the time remap to only cover a portion of the animation? If so, what's the behavior? I would guess frames outside of the remap would play as normal. It may be worth explicitly calling this out.
There was a problem hiding this comment.
The input/domain range is fixed (
There was a problem hiding this comment.
I think I got it, so first keyframe MUST equal ip and last MUST equal op ?
I suspect this is more of a general keyframe requirement? So may make sense to document it there (as a separate PR).
There was a problem hiding this comment.
Usually there's no timing requirements for keyframes (other than being strictly increasing), I don't recall tm being special in that case. Values before the first keyframe or after the last just have the same value as that keyframe.
There was a problem hiding this comment.
Yeah - Brandon, think of tm as just a regular animatable property (which it basically is). There are no special rules around its input range, it can be evaluated for the whole layer timeline just like all other animatable properties.
I think iOS didn't handle the timing correctly and had horrible performance when using time remapping |
Tested against the latest iOS tree (emulator), it appears to work now - maybe it was fixed? |
Could be, maybe we can ask them to review this? |
I asked Cal to take a look at this, and he confirmed that time remapping is supported on iOS. |
docs/static/examples/time_remap.json
Outdated
| } | ||
| ], | ||
| "markers": [], | ||
| "props": {} |
There was a problem hiding this comment.
is it necessary?
| "props": {} |
There was a problem hiding this comment.
Most likely not needed. Updated.
No description provided.