In exclusive fullscreen mode, the Window completely takes over drawing to a monitor and doesn't allow other windows to draw on that monitor, while the current mode just draws the window over the taskbar and without borders. Winit should definitely expose both modes, but the current API may be a bit misleading.
Where does this stand versus other operating systems? Do the other backends fully take over rendering to the monitor, or just draw over all other elements on the screen?
On wayland, the window asks the compositor to be displayed fullscreen, but does not take over the full monitor with the standard protocol. However, if the server supports the fullscreen shell extension, we can use it to request "real" fullscreen.
We used to have exclusive fullscreen on X11, though currently have borderless fullscreen instead. I'd be able to bring it back.
macOS has a bunch of different kinds of fullscreen modes as well, and I don't think the currently implemented one is idiomatic for games and such.
I'd also be in favor of having the API expose both exclusive and borderless fullscreen modes.
I found it surprising that this was missing! High-resolution displays are getting increasingly common, and in order to cover the entire screen, on these displays we are forced to create a window the size of the native display resolution, which could be as high as 3840x2160. Since we cannot render intensive graphics at this high of a resolution on most machines, using borderless fullscreen incurs an additional blit from a lower resolution render target to a higher resolution swapchain image, which is a performance issue.
I could look into putting together a pull request for the Windows and macOS platforms, but I'm unsure as to how to proceed with the rest of the platforms. I'm not interested in having to write this for the web and mobile platforms, as I'm not planning to ship anything on those platforms. Perhaps these platforms don't even have the concept of exclusive fullscreen?
For exclusive fullscreen mode we would also want a way to query the available video modes (issue #877).
For exclusive fullscreen mode we would also want a way to query the available video modes (issue #877).
Assuming you only want dimensions, we already expose those:
https://docs.rs/winit/0.19.1/winit/struct.EventsLoop.html#method.get_available_monitors
https://docs.rs/winit/0.19.1/winit/struct.MonitorId.html#method.get_dimensions
I've been thinking about how the API should look for this one, and I think we should do something like .with_fullscreen(Fullscreen::Exclusive(video_mode)) in the WindowBuilder where video_mode is a VideoMode retrieved from MonitorHandle::video_modes. VideoMode could contain the monitor handle to ensure that a video mode for the wrong monitor isn't passed in. We would also like to have Fullscreen::Borderless(monitor_handle) and Fullscreen::None variants for the current behaviour. We would also modify the fullscreen and set_fullscreen methods in Window to use the Fullscreen enum.
Most helpful comment
I found it surprising that this was missing! High-resolution displays are getting increasingly common, and in order to cover the entire screen, on these displays we are forced to create a window the size of the native display resolution, which could be as high as 3840x2160. Since we cannot render intensive graphics at this high of a resolution on most machines, using borderless fullscreen incurs an additional blit from a lower resolution render target to a higher resolution swapchain image, which is a performance issue.
I could look into putting together a pull request for the Windows and macOS platforms, but I'm unsure as to how to proceed with the rest of the platforms. I'm not interested in having to write this for the web and mobile platforms, as I'm not planning to ship anything on those platforms. Perhaps these platforms don't even have the concept of exclusive fullscreen?
For exclusive fullscreen mode we would also want a way to query the available video modes (issue #877).