rust-windowing
Fullscreen (exclusive) crashes when used with DXGI flip mode surfaces
Afaik DXGI flip model surfaces (https://devblogs.microsoft.com/directx/dxgi-flip-model/) don't support exclusive fullscreen, only borderless fullscreen. In Bevy we've had some users running into crashes because they're setting the window to fullscreen instead of borderless, but if they're using the dx12 backend (which is using dxgi flip model surfaces) or if they're using vulkan and a recent AMD (seems to automatically be using dxgi flip model now) or Nvidia (has a driver toggle to use dxgi flip model) driver it'll crash. (idk about intel)
Would it be possible for winit to detect if it's using a dxgi flip model surface and automatically fall back to borderless instead of exclusive fullscreen?
The d3d12 swapchain, which specifies the flip mode, is created in wgpu not in winit. We don't interface with DXGI in the Windows backend, so I feel like this is not an issue which should be handled inside winit.
This is something that needs to be fixed at the graphics api (eg. wgpu)/engine level, and can't be fixed in winit afaik. On dx12 I'd probably just disable fullscreen exclusive as you're going to be using a flip mode DXGI surface there anyways.
Eg. with vulkan you need to check https://registry.khronos.org/vulkan/specs/latest/man/html/VK_EXT_full_screen_exclusive.html
Example on how to do it: https://github.com/KhronosGroup/Vulkan-Samples/tree/main/samples/extensions/full_screen_exclusive
Could there be any other fixes for this, @Elabajaba ? This has been a problem for many of my own users and I've yet to find solutions for bevy. Most devices get a significant input lag reduction from exclusive fullscreen, yet new AMD cards crash on it. I'm not sure if VK_EXT_full_screen_exclusive nor Win32 calls can be trusted if AMD drivers are insisting flip mode on the driver level.
We also experience this bug in winit, but not SDL (using a vulkan backend). Even tho the vulkan backend is an almost direct port of the cpp version (using the same extensions): https://github.com/ddnet/ddnet-rs
One thing the cpp version definitely does what the rust version does not is having a windows manifest file, for comaptibility to Windows 7: https://github.com/ddnet/ddnet/blob/8bb8a173144455926f33b27b9ca40636008182e5/other/manifest/client.manifest.in
I tested it with odin and sdl2 and indeed no problemo. I testen it with c++ and sdl3 using the default 2d renderer and also no issue. Same machine. Just want te be sure is not my machine or driver issue..
Could adding that manifest to the winit version work, @Jupeyy @Retrodad0001 ? Sadly I can't reproduce this bug so I can't test this. Some resources I found on how to add a manifest to rust executables:
https://docs.rs/embed-manifest/latest/embed_manifest/
https://dev.to/carey/embed-a-windows-manifest-in-your-rust-program-26j2
If @Retrodad0001 can reproduce this issue on his rendering system even without a manifest file it's probably unrelated. Was just a random guess from me because I once read on Windows there is some kind of legacy fullscreen behavior like this:
I personally don't even use Windows
Could there be any other fixes for this, @Elabajaba ? This has been a problem for many of my own users and I've yet to find solutions for bevy. Most devices get a significant input lag reduction from exclusive fullscreen, yet new AMD cards crash on it. I'm not sure if VK_EXT_full_screen_exclusive nor Win32 calls can be trusted if AMD drivers are insisting flip mode on the driver level.
Most devices don't get much if any input lag reductions from exclusive fullscreen these days since afaik most devices are now giving out flip mode swap chains for Vulkan.
On the directx side the latency reduction basically hasn't been true for nearly a decade at this point (assuming DX12 or properly configured DX11 using flip model). Fullscreen exclusive is just one of those things a lot of gamers like to complain about because they're still parroting what was true 20 years ago, but hasn't been true for the last decade.
Could there be any other fixes for this, @Elabajaba ? This has been a problem for many of my own users and I've yet to find solutions for bevy. Most devices get a significant input lag reduction from exclusive fullscreen, yet new AMD cards crash on it. I'm not sure if VK_EXT_full_screen_exclusive nor Win32 calls can be trusted if AMD drivers are insisting flip mode on the driver level.
Most devices don't get much if any input lag reductions from exclusive fullscreen these days since afaik most devices are now giving out flip mode swap chains for Vulkan.
On the directx side the latency reduction basically hasn't been true for nearly a decade at this point (assuming DX12 or properly configured DX11 using flip model). Fullscreen exclusive is just one of those things a lot of gamers like to complain about because they're still parroting what was true 20 years ago, but hasn't been true for the last decade.
This is incorrect, we have a lot of players on ddnet that only play on fullscreen because all other modes have input lag, or have fewer fps. Except you tell me whatever SDL gives as fullscreen is not exclusive, which I doubt because on Windows the real fullscreen still blacks out your screen for a split second when tabbing in & out.
@Elabajaba will you reopen the issue btw? Else I create a new issue, because besides fullscreen not working, it also crashes the application without any way to recover from it.
So winit will have to deal with this issue in some way, anyway. (And be it just adding proper documentation that this is a real problem on Windows)
If the crash has a stack trace originating in winit, then it's a winit issue, but all the suggestions here say otherwise.
If the crash has a stack trace originating in winit, then it's a winit issue, but all the suggestions here say otherwise.
That's not my point tho.
- If winit does not mention at least in the docs that fullscreen will crash the app on windows, then you will get many issues like this over the years
- If winit creates a window with wrong parameters, it might also not crash inside winit, so it still is a possibility that this is a winit issue
If winit does not mention at least in the docs that fullscreen will crash the app on windows, then you will get many issues like this over the years
We can not account for every possible platform quirk in the docs, and if we do, no one will read that anyway or follow, better to just have workarounds in place where possible inside winit.
If winit creates a window with wrong parameters, it might also not crash inside winit, so it still is a possibility that this is a winit issue
Then open a separate issue with the enough details and not comment on this one?
We can not account for every possible platform quirk in the docs, and if we do, no one will read that anyway or follow, better to just have workarounds in place where possible inside winit.
Ofc that would be even better ^^
Then open a separate issue with the enough details and not comment on this one?
When I get hands on Windows again I'll see if there are any window properties (or whatever) that could be different between the SDL created window and this. If you prefer a new issue that is totally fine to me, hence me original question if this issue will be reopened.
I am a window management nobo tho, else I'd not use an abstraction like winit :D