Iced: Window flashes white before showing expected content

Created on 4 Apr 2020  路  4Comments  路  Source: hecrj/iced

Hey! Thanks for your works regarding GUIs in Rust.

I have noticed that running an example (the solar system example) shows the window without any contents for some time, before actually showing the solar system contents. I used to create hidden windows and then set them to visible only after the first drawing finished. Even though this technically delays the first response of the app, it heavily improves how the user perceives the responsiveness of an app: There is no untouchable "undefined state" to be seen before the real app is available. (Technically delaying should not be a problem though, because apps with very long startup times should use a loading bar in the opened app anyways).

Also, it should be only a few lines to add that behaviour:

winit/application.rs, line 154:

    window_builder = window_builder
                .with_visible(false) // add this
                .with_title(&title)
                // ...

winit/application.rs, line 213:

        window.request_redraw();
        window.set_visible(true); // show just before entering the loop? (maybe even inside the first loop iteration)

        event_loop.run(move |event, _, control_flow| match event {
             // ...

This probably has low priority. But it's only a few lines of code. I can submit a PR if you want to.

Do you think this is desirable?

improvement

Most helpful comment

Just to be clear: The startup time is not long at all on my machine, but on a dark background, with the solar system example, even a single frame flashing white is very irritating. I'll investigate some more.

All 4 comments

Yes, I believe it may be a good idea in general.

However, it would be more desirable to find out the cause of the delay and try to improve it, instead of working around it.

On my machine, the startup time of the solar_system is around 170-200 ms. I believe most of this time is spent initializing the renderer (requesting an adapter, creating the swapchain, etc.). It would be great if we could measure this properly and figure out if we can reduce it.

While it is always great to reduce startup time, I wouldn't call the delaying of the window a workaround, but rather call it a tradeoff that should always be done, however small the startup time may be. In a perfect world, one would maybe render to a buffer before creating a window at all, but in this world, we can't.

I just tried out the delayed showing, but still had to witness that it still flashed white before actually showing the content. Maybe this is also a problem with Windows that must be solved in a different way?

Just to be clear: The startup time is not long at all on my machine, but on a dark background, with the solar system example, even a single frame flashing white is very irritating. I'll investigate some more.

200ms is about 15 frames, so yeah, definitely should be hidden until first draw. A decent rule of thumb would be show it after, say, 500ms if it hasn't drawn yet.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Plecra picture Plecra  路  4Comments

twitchyliquid64 picture twitchyliquid64  路  4Comments

aentity picture aentity  路  4Comments

jiminycrick picture jiminycrick  路  3Comments

aentity picture aentity  路  3Comments