Hello, is it expected that `ImageComposeScene` ren...

# compose-desktop

[louiscad]

Hello, is it expected that ImageComposeScene renders one frame late, or just renders wrong?

I am using this composable where I call render repeatedly on the same ImageComposeScene , but with ever increasing nanoTime values, and I only get the correct render if I call render a second time, which is quite of a dirty workaround.

@Composable
fun JustFrameNumberComposable() {
    val frameNumber by produceState(0L) {
        while (true) withFrameMillis { frameTimeMillis ->
            value = frameTimeMillis * 60L / 1000L
        }
    }
    Text("Frame number: $frameNumber")
}

[Alexander Maryanovsky]

It’s expected, given this code.
The phases of rendering are composition, layout, drawing, effects.
In the code you gave, produceState runs in an effect, so the first time render is called, it sets the value, but composition and drawing (with the default value) has already happened.

[Alexander Maryanovsky]

It’s not about ImageComposeScene; the same will be with a regular window - the first frame will show the default value.

[louiscad]

Is calling render twice the correct way to handle this?

[louiscad]

It's not the most expensive part of what I'm doing anyway… The bottleneck is saving those to WEBPs in parallel based on the number of CPU cores so they can be fed to FFMPEG and generate a transparent .mov with Apple ProRes 4444 encoding.

[Alexander Maryanovsky]

You don’t have to call it twice, just take into account that after each call, the text will be with the previous value.

[louiscad]

There's no way to do pixel & time perfect animations?

[Alexander Maryanovsky]

Not sure what you mean by that.

[louiscad]

I'd like that at a given frame time, I know exactly what will be shown

[louiscad]

I'm generating overlays based on timecodes for video editing (not live)

[Alexander Maryanovsky]

You do. It’s just always the value of the previous render call.

[louiscad]

Isn't the issue caused by this in Application.desktop.kt?

private object YieldFrameClock : MonotonicFrameClock {
    override suspend fun <R> withFrameNanos(
        onFrame: (frameTimeNanos: Long) -> R
    ): R {
        // We call `yield` to avoid blocking UI thread. If we don't call this then application
        // can be frozen for the user in some cases as it will not receive any input events.
        //
        // Swing dispatcher will process all pending events and resume after `yield`.
        yield()
        return onFrame(System.nanoTime())
    }
}

To me, the yield() should come after onFrame(…) in a finally block, or after with the result of onFrame being put in a local val.

[Alexander Maryanovsky]

I’m afk so can’t be sure, but I don’t think that code is relevant when you use ImageComposeScene. You drive the render loop manually, with your own frame times, when you use ImageComposeScene.