Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: Fullscreen mode is borderless window, not exclusive fullscreen #717

Closed
Osspial opened this issue Nov 19, 2018 · 5 comments · Fixed by #925
Closed

Windows: Fullscreen mode is borderless window, not exclusive fullscreen #717

Osspial opened this issue Nov 19, 2018 · 5 comments · Fixed by #925
Labels
C - needs discussion Direction must be ironed out D - average Likely as difficult as most tasks here P - high Vital to have S - api Design and usability

Comments

@Osspial
Copy link
Contributor

Osspial commented Nov 19, 2018

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?

@elinorbgr
Copy link
Contributor

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.

@francesca64 francesca64 added S - api Design and usability C - needs discussion Direction must be ironed out labels Nov 19, 2018
@francesca64
Copy link
Member

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.

@ghost
Copy link

ghost commented Jun 2, 2019

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).

@goddessfreya
Copy link
Contributor

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

@goddessfreya goddessfreya added D - average Likely as difficult as most tasks here P - high Vital to have labels Jun 2, 2019
@ghost
Copy link

ghost commented Jun 6, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C - needs discussion Direction must be ironed out D - average Likely as difficult as most tasks here P - high Vital to have S - api Design and usability
Development

Successfully merging a pull request may close this issue.

4 participants