Search Issue Tracker
By Design
By Design in 6000.5.X
Votes
0
Found in
6000.0.61f1
6000.2.12f1
6000.3.0b10
6000.4.0a5
6000.5.0a1
Issue ID
UUM-126768
Regression
No
deltaTime and unscaledDeltaTime discrepancy when Player window is moved to secondary monitor and VSync is enabled
How to reproduce:
1. Open the attached “IN-123633_Archive 2.zip” project
2. Build and run the player
3. Press Alt + Enter to exit out of fullscreen
4. Drag the Player to a secondary monitor
5. Open the Player.log (Can be found in Appdata → LocalLow → DefaultCompany → AnimationSlowed)
6. Observe the Player.log
Expected result: There is no difference between deltaTime and unscaledDeltaTime
Actual result: Script logs discrepancies between deltaTime and unscaledDeltaTime
Reproducible on: Windows 11 Pro (24H2), MacOS Sequoia 15.7.2 (M3), MacOS 26.1
Not reproducible on: No other environments tested
Reproducible with: 2023.1.0a1, 6000.0.61f1, 6000.2.12f1, 6000.3.0b10, 6000.4.0a5, 6000.5.0a1
Note: Does not reproduce on Vulkan
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
- Build fails when building a project containing an 18+ dimension array with IL2CPP
- [Android][Sentis] Human poses are not detected when using the BlazePose model
- Sprite Editor Outline Tool Overlay is not displayed when no Sprite is selected
- “No method with RuntimeInitializeOnLoadMethod attribute” warning from ReadmeEditor.cs is thrown after installing Project Auditor Rules
- Projection matrix is altered when using RasterCommandBuffer.ClearRenderTarget on DX12 and Metal
Resolution Note:
After a deep dive into the timing issues you've been seeing, we’ve identified that the root cause lies within how Nvidia and Microsoft handle DirectX timestamps, rather than Unity itself.
To provide context on the architecture: both unscaledDeltaTime and deltaTime are calculated using timeSinceStartup (via GfxDevice), but they utilize different offsets. While deltaTime uses m_ZeroTime (which we frequently update and clamp to safe ranges), unscaledDeltaTime relies on m_RealZeroTime, which is only updated during a begin/reset cycle. When reset is called they are both the same i.e m_RealZerotime = m_ZeroTime (so deltaTime and unscaledDeltaTime should be briefly same if scaling factor is 1.0). So these are different by design.
The 'slow-motion' behavior occurs when timeSinceStartup fails to reflect reality. Because GetLastPresentTime on Windows is notoriously unreliable, we have implemented several stabilization workarounds. You may still observe erratic delta values for the first ~10 frames, but should get better values over time once the workarounds kick in.
We have escalated this to both partners. Microsoft recently clarified that these inconsistent DirectX timestamps are 'by design' and will not be patched. Nvidia has assigned a bug ticket to the issue, but we have not yet received a progress update. We understand this isn't the ideal resolution, but we are currently operating at the limit of what the OS and drivers provide.
Resolution Note (6000.5.X):
After a deep dive into the timing issues you've been seeing, we’ve identified that the root cause lies within how Nvidia and Microsoft handle DirectX timestamps, rather than Unity itself.
To provide context on the architecture: both unscaledDeltaTime and deltaTime are calculated using timeSinceStartup (via GfxDevice), but they utilize different offsets. While deltaTime uses m_ZeroTime (which we frequently update and clamp to safe ranges), unscaledDeltaTime relies on m_RealZeroTime, which is only updated during a begin/reset cycle. When reset is called they are both the same i.e m_RealZerotime = m_ZeroTime (so deltaTime and unscaledDeltaTime should be briefly same if scaling factor is 1.0). So these are different by design.
The 'slow-motion' behavior occurs when timeSinceStartup fails to reflect reality. Because GetLastPresentTime on Windows is notoriously unreliable, we have implemented several stabilization workarounds. You may still observe erratic delta values for the first ~10 frames, but should get better values over time once the workarounds kick in.
We have escalated this to both partners. Microsoft recently clarified that these inconsistent DirectX timestamps are 'by design' and will not be patched. Nvidia has assigned a bug ticket to the issue, but we have not yet received a progress update. We understand this isn't the ideal resolution, but we are currently operating at the limit of what the OS and drivers provide.