Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Window flashes with default background color when shown initially #1794

Closed
m-sasha opened this issue Feb 4, 2022 · 9 comments · Fixed by JetBrains/compose-multiplatform-core#442
Assignees
Labels
desktop ui glitch Visual glitch in UI, usually not blocking normal usage wait for build

Comments

@m-sasha
Copy link
Contributor

m-sasha commented Feb 4, 2022

On Mac OS X (haven't checked other platforms), the simplest application showing a window filled with some color will flash the default background color for a split second. This is unnoticeable with a light theme, but is very annoying with a dark theme.

window.flash.mp4
fun main() = singleWindowApplication(
    state = WindowState(
        width = 800.dp,
        height = 600.dp,
    )
) {
    Surface(
        color = Color.Black,
        modifier = Modifier.fillMaxSize()
    ){ }
}

This happens because JFrame sets its background in frameInit to UIManager.getColor("control").
Even setting

window.background = java.awt.Color(0, 0, 0)

inside the singleWindowApplication content doesn't help because it seems the window has drawn itself by the time it's called.

What does help is calling

UIManager.put("control", java.awt.Color(0, 0, 0))

before the call to singleWindowApplication.

@Thomas-Vos
Copy link
Contributor

Running into the same issue, on macOS you can indeed fix it using the UIManager workaround. However, on Windows it is still an issue. I have not found a fix for Windows yet.

It appears that the window is shown before the Compose UI code, which seems unexpected to me. Maybe the window should be hidden until the first frame?

igordmn added a commit to JetBrains/compose-multiplatform-core that referenced this issue Feb 8, 2022
Fixes JetBrains/compose-multiplatform#1794

If the first frame is too long to draw (> 500ms), users should make their apps asynchronous and draw UI gradully in multiple frames without blocking the UI thread for too long in single frame
@igordmn igordmn added ui glitch Visual glitch in UI, usually not blocking normal usage wait for build desktop labels Feb 8, 2022
@igordmn igordmn self-assigned this Feb 8, 2022
@igordmn
Copy link
Collaborator

igordmn commented Feb 27, 2022

In 1.1.0 we draw the first frame offscreen.

If the application has too long start after this change, we can measure the first frame, and move the heavy logic to background or to the next frames. We can measure the first frame with this snippet:

import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.setValue
import androidx.compose.ui.window.singleWindowApplication

private var time by mutableStateOf(System.nanoTime())
private var frame by mutableStateOf(0)

fun main() = singleWindowApplication {
    if (frame == 0) {
        frame++
    } else if (frame == 1) {
        val duration = ((System.nanoTime() - time) / 1E6).toLong()
        println("First frame millis: $duration")
    }
}

@igordmn igordmn closed this as completed Feb 27, 2022
copybara-service bot pushed a commit to androidx/androidx that referenced this issue Mar 1, 2022
Fixes JetBrains/compose-multiplatform#1794
Fixes JetBrains/compose-multiplatform#1652

If the first frame is too long to draw (> 500ms), users should make their apps asynchronous and draw UI gradually in multiple frames without blocking the UI thread for too long in single frame.

Change-Id: I3f01c963478bf23ee75e4adeb45a172b25591073
Test: ./gradlew jvmTest desktopTest -Pandroidx.compose.multiplatformEnabled=true
igordmn added a commit to JetBrains/compose-multiplatform-core that referenced this issue Mar 28, 2022
Fixes JetBrains/compose-multiplatform#1794

If the first frame is too long to draw (> 500ms), users should make their apps asynchronous and draw UI gradully in multiple frames without blocking the UI thread for too long in single frame

# Conflicts:
#	compose/ui/ui/src/desktopTest/kotlin/androidx/compose/ui/window/TestUtils.kt
#	compose/ui/ui/src/desktopTest/kotlin/androidx/compose/ui/window/dialog/DialogTest.kt
#	compose/ui/ui/src/desktopTest/kotlin/androidx/compose/ui/window/window/WindowTest.kt
@m-sasha
Copy link
Contributor Author

m-sasha commented Feb 7, 2023

Looks like we have a regression here. This happens maybe 25% of the times the app is launched:

fun main() = application {
    val windowState = rememberWindowState(size = DpSize.Unspecified)
    Window(onCloseRequest = ::exitApplication,
        state = windowState,
    ) {
        Box(modifier = Modifier.background(Color.DarkGray).size(300.dp)) {
            Text("BOX", modifier = Modifier.align(Alignment.Center))
        }
    }
}
Screen.Recording.2023-02-07.at.9.30.20.mp4

Compose 1.3.0
Mac OS X 13.1
Kotlin 1.8.0

@m-sasha m-sasha reopened this Feb 7, 2023
@m-sasha m-sasha self-assigned this Feb 12, 2023
@m-sasha
Copy link
Contributor Author

m-sasha commented Mar 18, 2023

The problem seems to be in Skiko, not Compose.

@m-sasha
Copy link
Contributor Author

m-sasha commented Mar 18, 2023

Actually, maybe not. The reproducer I was trying to get in Skiko was doing it wrong.

@m-sasha
Copy link
Contributor Author

m-sasha commented Mar 18, 2023

Ok, the culprit here is size = DpSize.Unspecified. When using a specific size the background color doesn't flash.

I'm guessing that it happens because it requires an extra layout pass to determine the composition size, so the window is drawn before the composition is drawn at its final size.

@igordmn
Copy link
Collaborator

igordmn commented Mar 20, 2023

so the window is drawn before the composition is drawn at its final size.

To avoid flickering, we draw the first frame before isVisible = true.

When we don't specify the size, we call contentSize that do one additional implicit layout pass.

Maybe we do it after we draw the first frame. In this case, the fix will be to move calling contentSize before drawing the first frame.

@m-sasha
Copy link
Contributor Author

m-sasha commented Mar 20, 2023

I figured out why it's happening...

@m-sasha
Copy link
Contributor Author

m-sasha commented Mar 24, 2023

Note that the problem still exists when opening a Maximized window. Fixing that too clashes with being able to use an Unspecified "unmaximized" size for the window to go back to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
desktop ui glitch Visual glitch in UI, usually not blocking normal usage wait for build
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants