In the documentation for `withFrameMillis` it states: “Time values provided are monotonically increa...

# compose

[Trevor Stone]

In the documentation for withFrameMillis it states: “Time values provided are monotonically increasing; after a call to withFrameMillis completes it must not provide a smaller value for a subsequent call”. I am using compose in a non-android and non-UI context in this case. If I provide a custom clock and don’t follow this guideline (frame 100 might come before frame 3) am I going to run into issues? Is the rule about monotonically increasing frame times enforced in the core compose runtime somehow?

[jw]

The timestamp is not used by Compose. For the first two years of my non-UI Compose usage I simply supplied 0.

[jw]

However, if you want users of your Composables to rely on the frame time for things like animation progression, you will want to honor this.

[Robert Jaros]

I supply simple incremental long value

[jw]

On what platform are you running? It's not too hard to find a clock that can give you this guarantee. Molecule should have one for every platform the Compose runtime works on which you can copy.

[jw]

Incrementing long means you can't use it for time-based progression of values. You might as well provide 0 at that point.

[Robert Jaros]

Currently I'm fine with this but I'll be happy to see better solution working on nodejs.

[jw]

Huh, we don't have a NodeJS clock. Only a browser clock. I guess I know what I'm doing next week (off this week).

[Robert Jaros]

Nodejs on both JS and WasmJs please 😛

[jw]

There is no stable runtime for wasm yet.

[Robert Jaros]

I just need to copy, so unstable branch will be good enough 😉

[jw]

Haha. Well I'll file an issue for it and maybe someone else will pick it up. I'm woefully under-experienced in wasm, and somewhat content to leave it that way until i can use regular dependencies.

[Robert Jaros]

Joking aside, I'll manage to make wasmJs/node version on my own, having js/node example :)

[Doris Liu]

If I provide a custom clock and don’t follow this guideline (frame 100 might come before frame 3) am I going to run into issues?

You might run into issues if you have animations consuming the timestamps produced by the clock. Animations calculates the playtime as currentFrameTime - startTime, where startTime is frame time of the first animation tick. If the frame time is decreasing, we could end up with negative playTime, which could lead to undefined behavior in animation.

[Trevor Stone]

Thanks. Because this is a non-UI project I am building this all sounds like my idea will work ok. My project will target as many platforms as possible, but I am planning to implement a custom clock for my use-case