Black screen until resize starting in wgpu 23

[LPGhatguy]

Description
Starting in wgpu 23, our game renders a couple frames, then the screen turns black until the window resizes. After that, the problem goes away.

This doesn't happen in wgpu 22 or earlier.

I've only had access to a macOS machine running under MoltenVK; I don't know if this bug reproduces on other platforms.

I apologize that I don't have a lot of details on this issue yet and wgpu on MoltenVK is a funky platform. I'm hoping that there's something that might be an obvious cause of this issue. If not, I'll get any other information needed.

Repro steps
Working on minimizing this case right now; wanted to get this issue on the radar while I work through the problem.

get_current_texture is returning a texture every frame, so the swapchain is up to date, but nothing is being presented.

Expected vs observed behavior
Expected behavior (wgpu 22):

main.branch.mp4

Observed behavior (wgpu 23, no other changes):

wgpu.23.mp4

Extra materials
Running with the Vulkan Configurator, there are no new validation errors in wgpu 23 vs wgpu 22.

Platform
MacBook Pro with M3 Pro
macOS 14.6.1 with MoltenVK included in Vulkan SDK 1.3.296.0
wgpu 23.0.1

[jameskr97]

I also came across this issue using wgpu 23 with winit latest main branch.

In my case, winit doesn't make it easy to call async functions from the event loop, so I had to come up with a way to synchronize the wgpu async calls with the non-async ApplicationHandler of winit.

The wgpu examples use winit-0.29, which is notably different in the following way:

• winit::window::WindowBuilder has been removed as a way to create a window in winit-0.30, and the intended way is now with ActiveEventLoop::create_window, which is called by winit behind the scenes.

Here is an example I found: https://github.com/erer1243/wgpu-0.20-winit-0.30-web-example that gets the two working together.

I was able to work around it by calling winit::window::Window::request_redraw() after all my wgpu resources were setup properly.

[jameskr97]

Came across this when looking at some wgpu examples. Possibly related?
rust-windowing/winit#3235

[LPGhatguy]

@jameskr97 I ran into a similar winit issue when I upgraded to winit 0.30. We had to start calling window.request_redraw or we would never get a RedrawRequested event on macOS. We still end up with a black screen.

[jameskr97]

@jameskr97 I ran into a similar winit issue when I upgraded to winit 0.30. We had to start calling window.request_redraw or we would never get a RedrawRequested event on macOS. We still end up with a black screen.

For me, I would get an initial RedrawRequested, but it was before wgpu resources were created. Because we're just able to call the window.request_redraw, I'm not sure if this is really an issue or just something to be documented as a required function to call somewhere in the wgpu init process.