pink screen on startup

[mockersf]

Bevy version

main since #20002

[Optional] Relevant system information

I saw it on macOS, but I don't know if it's present on other platforms

What you did

cargo run --release --example 3d_shapes

What went wrong

a pink screen flashes

Additional information

pink.mp4

[alice-i-cecile]

I'd like a proper fix, but I am prepared to revert the linked PR before release if no fix is forthcoming.

[hymm]

tested on windows and I just get the typical all white window. Don't see any pink.

[viridia]

That looks like fuchsia (#ff00ff) which is often used as a placeholder - precisely because it is so garish and obnoxious.

[Zeophlite]

Isolated this to the BlitPlugin changes

[cart]

Its worth fixing this for 0.17 in whatever way we can, but this feels like some sort of "order of operations" issue. It would be good to understand what the actual problem is here so we can know the limitations of RenderStartup: what should be ported over and what shouldn't be? Currently the approach has been "move everything over", but this is an indicator that we can't just do that blindly. Can one of the drivers of the RenderStartup effort (@IceSentry or @andriyDev) look into this?

[andriyDev]

The Lore

Ok let me summarize my understanding. This is an unfortunate interaction between two changes: the switch of shaders to embedded assets, and RenderStartup.

In 0.16, shaders were inserted directly into Assets at plugin build time. The shaders were then extracted to the render world, and then the render pipelines were built. The blit pipeline in particular was blocked on so it definitely would be ready.

Then we switched to load_embedded_asset for our shaders (which let our shaders for reload). However, this meant two things: 1) shaders were only being loaded when requested (when we call asset_server.load), 2) shaders were now being loaded asynchronously (a task would be spawned to load the shader, and the shader would only be added to Assets when the task finished and the handle_internal_asset_events system runs in the main world). I think even in this state, the pink screen was possible (though unlikely). If the blit shader took too long to load (e.g., there were too many assets to load and that task just wasn't picked up in time), it wouldn't be added by handle_internal_aaset_events, so it wouldn't be extracted, so the pipeline couldn't be compiled, so the buffer would remain pink. This is highly unlikely though, because we have the entire first game frame to load the shaders roughly and most of the big assets are loaded in Startup instead of plugin build time.

Then we added RenderStartup. RenderStartup moved all the shader loads to the extract schedule effectively. This means that even if shaders loaded instantly, they were after handle_internal_asset_events so the shader would not be inserted into the ECS, the shader would not be extracted, and the pipeline could not be compiled - and so, the pink screen.

The Fixes

1. use load_shader_library instead of embedded_asset for shaders. This would get us back to the state before RenderStartup. We would still be embedding the asset, and we'd be starting the load of these shaders at plugin build, so it'll hopefully load by the time handle_internal_asset_events and blah blah, screen no pink.

2. Revert RenderStartup for broken stuff. This is not a very reliable solution since we don't know what's broken until we see it.

3. Make Startup real. Today, Startup is actually part of the update schedule. RenderStartup is similar, though it's actually part of extract. Instead, we could add a startup schedule label to App (or similar), then run those first (so Startup and RenderStartup happen "early"), then start the actual main loop. This way we start loading the shaders before the first frame (like before), so they'll almost certainly be loaded just like before.

4. Revert embedded assets. That would mean the shaders are inserted directly, but we lose shader for hot reloading.