Godot: when toggling between fullscreen, the screen freezes

Created on 28 Jan 2019  路  14Comments  路  Source: godotengine/godot

Godot version:
188a711c4f08f96bccd72ecea0d7445f0c7846ca

OS/device including version:
Win10, 64-bit. GTX 950, nvidia driver 399.24

Issue description:
When toggling between fullscreen mode, the Godot app will freeze for a few seconds

Steps to reproduce:

  • Run example project
  • Click the Fullscreen button
  • Now press windows key + d, alt+tab, or click it again
  • You will notice a screen freeze for 2-3 seconds ( seems like the entire app locks up too, because the button doesn't get changed until a few seconds later)

Other Information:

  • happens on exported builds as well

Minimal reproduction project:
New Game Project67.zip

archived bug windows rendering

Most helpful comment

Indeed, I can confirm this on Windows 10, AMD FirePro D300:

  • setting window_fullscreen or setting window_borderless and window_size to get_screen_size() - screen turns off for about 2 sec (if multiple monitors connected only one with the app is turned off), after turning back button state is change and no freeze visible. On switching back all monitors turns off for the same delay.
  • setting window_size to get_screen_size() + Vector2(0, 1) - instant switch forth and back.

On macOS get_screen_size() and get_screen_size() + Vector2(0, 1) behaves identically (instant switch), setting window_fullscreen plays usual macOS zoom and slide animation with no additional freeze.

No idea why that's happening.

All 14 comments

I can't reproduce this on Linux, but this is likely Windows-specific due to how fullscreen is implemented there.

Does the freeze occur if you enable borderless in the Project Settings?

ty @Calinou
yes, can confirm, just enabled borderless and freeze still occurs
edit: possible culprit somewhere in here maybe
https://github.com/godotengine/godot/blob/2c9536b655d006c697a3cf830ad3352f1a1ed9f2/platform/windows/os_windows.cpp#L1795

I have noticed when you go fullscreen it's actually fast / normal. But when fullscreen gets disabled, is when it locks up.

I've been fiddling around with this for a few hours:

Replace the example code with:

extends Control

var old_size = OS.window_size
var old_position = OS.window_position  

func _on_CheckButton_toggled(button_pressed):
    if button_pressed:
        OS.window_borderless = true
        OS.window_size = OS.get_screen_size() + Vector2(0, 1)
        OS.window_position = Vector2(0, 0)
    else: 
        OS.window_size = old_size
        OS.window_position = old_position
        OS.window_borderless = false

The app doesn't freeze when toggling between fullscreen now. Mind is absolutely blown. Seems like whenever window_size is equal to the user's screen resolution exactly is when the freeze occurs

Was always thinking that was a normal to have some delay from switching in and out of full screen.

Couldn't see any improvement with the work around suggested, wondering what I may be missing.

@avencherus Yeah, I re-worded my previous post, my bad! Basically, whenever Vector2(0, 1) is added to OS.window_size, the freeze will not happen. However, the screen stretches 1 pixel too long and cuts off your UI / looks a bit funky

It's happening whenever OS.window_size equals get_screen_size(). I'm using a NVIDIA card and I don't know if this is reproducible on AMD cards.

CC @bruvzg @hpvb

Indeed, I can confirm this on Windows 10, AMD FirePro D300:

  • setting window_fullscreen or setting window_borderless and window_size to get_screen_size() - screen turns off for about 2 sec (if multiple monitors connected only one with the app is turned off), after turning back button state is change and no freeze visible. On switching back all monitors turns off for the same delay.
  • setting window_size to get_screen_size() + Vector2(0, 1) - instant switch forth and back.

On macOS get_screen_size() and get_screen_size() + Vector2(0, 1) behaves identically (instant switch), setting window_fullscreen plays usual macOS zoom and slide animation with no additional freeze.

No idea why that's happening.

well then.. i can't reproduce this anymore on the recent 419.17 NVIDIA driver update

Was here test for some other issue but found out that this is not reproducible in latest master https://github.com/godotengine/godot/commit/4ee8ecd3efee742be58c1ff191e78d0de09b57b6 on Windows 10 1903 64bit with just Integrated Graphics(Intel HD Graphics 620).
Could be Graphics Driver bug.

@avencherus @bruvzg Can you still reproduce it on Windows 10?

@akien-mga Happens still in 393a0152e.

Not easily captured with video capture, so I'll describe it.

  1. It shows a black screen with the window lingering over top for a few seconds.
  2. It flickers on both of my monitors. Seems to alternate though, as though it is jumping between them.
  3. Resolves to fullscreen.

It can be jarring and messy looking, but nothing exceptionally severe.

I've also noticed that launching the game into a code that does a resize of the window seems to send that Godot logo off center. (May be unrelated and haven't tested it very much. But could likely impact some people's opening splash screens in a very unprofessional way.)

godot windows tools 64_2019-09-23_12-15-16

@akien-mga I can't reproduce it in 393a0152e, Windows 10 - 1903, AMD driver 19.9.2, same hardware and display config as before. Fullscreen switching in instant, no freeze, no flickering. Sometime window frame switches to "Windows 7" style for a single frame, before going to full screen.

Update: Can't reproduce it with 3.1.1 stable too, probably it was driver issue.

Can be closed if not reproducible.

Looks like it was a driver issue.

Was this page helpful?
0 / 5 - 0 ratings