Search Issue Tracker
Won't Fix
Won't Fix in 6000.0.X, 6000.3.X, 6000.5.X
Votes
0
Found in
6000.0.58f1
6000.2.6f1
6000.3.0b2
6000.4.0a1
6000.5.0a1
Issue ID
UUM-119452
Regression
No
Player display resolution changes to the native resolution of the monitor when Player becomes unresponsive
How to reproduce:
1. Open the attached "IN-115604" project
2. Open the “SampleScene” scene
3. Build and run the Player (File > Build and Run)
4. Use the drop-down to change to a window resolution which is not the native resolution of the monitor
5. Click the "Freeze" button and start clicking anywhere in the Player window until Unity becomes unresponsive
6. Wait until Unity responds again
7. Observe the result
Expected result: Resolution stays the same
Actual result: Resolution changes back to native monitor resolution
Reproducible with: 2023.1.0a1, 6000.0.58f1, 6000.2.6f1, 6000.3.0b2
Reproducible on: Windows 11 Pro (24H2)
Not reproducible on: macOS 15.3 (M2 Ultra)
Notes:
- You can also change the resolution of the Player inside the project settings (Edit > Project Settings > Player > Resolution and Presentation)
- Bug is only reproducible in Fullscreen
- Bug breaks build, launching again or even rebuilding starts the Player in the native resolution of the monitor, to fix this you have to change the resolution of the build manually again
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- "Shader warning in 'Hidden/Light2D': implicit truncation of vector type" is thrown when building Universal 2D template
- AI Assistant breaks compilation of packages using System.Runtime.CompilerServices.Unsafe via auto-referencing
- Unity Hub checks the "Documentation" module by default on the 6.4 and 6.5 streams despite that it was unchecked with the previous installs
- Shortcut that toggles between Dopesheet and Curves Views in the Animation Window's Timeline is mislabed
- Property List Items Overlap onto the Property List's top edge when scrolling through a long Property List
Resolution Note:
Thank you for reporting a bug to Unity.
After investigation, this behaviour is driven by Windows/DWM window management rather than an error in Unity’s resolution handling.
Spy++ analysis shows that when the Player becomes unresponsive and recovers, Windows sends WM_SIZE (SIZE_RESTORED) messages that reapplies the monitor’s native window size. These messages cannot be distinguished from the WM_SIZE messages in scenarios such as moving the window between monitors (e.g. CTRL+WIN+LEFT/RIGHT).
As a result of this, the current behaviour is considered an OS-level constraint of fullscreen on Windows, and this issue will be closed as Won’t Fix, because:
- The Windows message sequences for freeze recovery and monitor switching are effectively the same
- Unity cannot reliably differentiate a “freeze recovery resize” from a valid OS-driven resize without using fragile workarounds
- There is no platform-safe way for Unity to preserve a previously requested non-native resolution across a freeze without introducing regressions
If you can identify the cause of the player becoming unresponsive, please report it as a separate bug so it can be investigated independently.
Today we will be closing this case. Thank you again for taking the time to report this issue, and please let us know if there is anything else that changes the impact or severity of this issue.
Resolution Note (6000.5.X):
Thank you for reporting a bug to Unity.
After investigation, this behaviour is driven by Windows/DWM window management rather than an error in Unity’s resolution handling.
Spy++ analysis shows that when the Player becomes unresponsive and recovers, Windows sends WM_SIZE (SIZE_RESTORED) messages that reapplies the monitor’s native window size. These messages cannot be distinguished from the WM_SIZE messages in scenarios such as moving the window between monitors (e.g. CTRL+WIN+LEFT/RIGHT).
As a result of this, the current behaviour is considered an OS-level constraint of fullscreen on Windows, and this issue will be closed as Won’t Fix, because:
- The Windows message sequences for freeze recovery and monitor switching are effectively the same
- Unity cannot reliably differentiate a “freeze recovery resize” from a valid OS-driven resize without using fragile workarounds
- There is no platform-safe way for Unity to preserve a previously requested non-native resolution across a freeze without introducing regressions
If you can identify the cause of the player becoming unresponsive, please report it as a separate bug so it can be investigated independently.
Today we will be closing this case. Thank you again for taking the time to report this issue, and please let us know if there is anything else that changes the impact or severity of this issue.
Resolution Note (6000.5.X):
Thank you for reporting a bug to Unity. After investigation, this behaviour is driven by Windows/DWM window management rather than an error in Unity’s resolution handling. Spy++ analysis shows that when the Player becomes unresponsive and recovers, Windows sends WM_SIZE (SIZE_RESTORED) messages that reapplies the monitor’s native window size. These messages cannot be distinguished from the WM_SIZE messages in scenarios such as moving the window between monitors (e.g. CTRL+WIN+LEFT/RIGHT). As a result of this, the current behaviour is considered an OS-level constraint of fullscreen on Windows, and this issue will be closed as Won’t Fix, because: - The Windows message sequences for freeze recovery and monitor switching are effectively the same - Unity cannot reliably differentiate a “freeze recovery resize” from a valid OS-driven resize without using fragile workarounds - There is no platform-safe way for Unity to preserve a previously requested non-native resolution across a freeze without introducing regressions If you can identify the cause of the player becoming unresponsive, please report it as a separate bug so it can be investigated independently. Today we will be closing this case. Thank you again for taking the time to report this issue, and please let us know if there is anything else that changes the impact or severity of this issue.
Resolution Note (6000.3.X):
Thank you for reporting a bug to Unity. After investigation, this behaviour is driven by Windows/DWM window management rather than an error in Unity’s resolution handling. Spy++ analysis shows that when the Player becomes unresponsive and recovers, Windows sends WM_SIZE (SIZE_RESTORED) messages that reapplies the monitor’s native window size. These messages cannot be distinguished from the WM_SIZE messages in scenarios such as moving the window between monitors (e.g. CTRL+WIN+LEFT/RIGHT). As a result of this, the current behaviour is considered an OS-level constraint of fullscreen on Windows, and this issue will be closed as Won’t Fix, because: - The Windows message sequences for freeze recovery and monitor switching are effectively the same - Unity cannot reliably differentiate a “freeze recovery resize” from a valid OS-driven resize without using fragile workarounds - There is no platform-safe way for Unity to preserve a previously requested non-native resolution across a freeze without introducing regressions If you can identify the cause of the player becoming unresponsive, please report it as a separate bug so it can be investigated independently. Today we will be closing this case. Thank you again for taking the time to report this issue, and please let us know if there is anything else that changes the impact or severity of this issue.
Resolution Note (6000.0.X):
Thank you for reporting a bug to Unity. After investigation, this behaviour is driven by Windows/DWM window management rather than an error in Unity’s resolution handling. Spy++ analysis shows that when the Player becomes unresponsive and recovers, Windows sends WM_SIZE (SIZE_RESTORED) messages that reapplies the monitor’s native window size. These messages cannot be distinguished from the WM_SIZE messages in scenarios such as moving the window between monitors (e.g. CTRL+WIN+LEFT/RIGHT). As a result of this, the current behaviour is considered an OS-level constraint of fullscreen on Windows, and this issue will be closed as Won’t Fix, because: - The Windows message sequences for freeze recovery and monitor switching are effectively the same - Unity cannot reliably differentiate a “freeze recovery resize” from a valid OS-driven resize without using fragile workarounds - There is no platform-safe way for Unity to preserve a previously requested non-native resolution across a freeze without introducing regressions If you can identify the cause of the player becoming unresponsive, please report it as a separate bug so it can be investigated independently. Today we will be closing this case. Thank you again for taking the time to report this issue, and please let us know if there is anything else that changes the impact or severity of this issue.