WM: improve timer precision for more precise playback #111603

Campbell Barton · 2023-08-28T10:11:59+02:00

Campbell Barton commented

2023-08-28 10:11:59 +02:00

When a timer needs to execute during the idle time (currently 5ms),
use microsecond precision to ensure the timer isn't delayed by the idle
time.

This improves the precision of animation playback on systems that support it
(WIN32, see note below).

In my tests FPS playback varied:

59.94 FPS would jitter between 58.13 & 63.11 FPS.
23.98 FPS would jitter between 23.68 & 24.31 FPS.

Using higher precision timers mostly resolves this issue although there
is still some jitter although it's now limited to ~0.01 FPS.

These values were measured with the FPS samples set to show real times
between frames (without them being smoothed out).

This is a continuation of a fix for #111579 which avoided the worst of the jittering issues at higher frame rates.

It appears WIN32 doesn't support sleeping shorter than 1 millisecond via std::this_thread::sleep_for, making this change have no benefit on WIN32, from tests it also doesn't have any down sides, so avoid platform specific logic. The WIN32 limitation is noted in code-comments. If a method of higher precision method is available this can be investigated.

To reproduce this error, set the FPS samples preference to 1, use the default scene and play animation either at 59.94 or 23.98 FPS.
Using a fractional FPS ensures a fractional FPS is displayed in the view-port.

NOTES:

The FPS error is roughly between 2.6 - 8.6% with the higher errors occurring at higher FPS (59.94) in this case, where they're less likely to be noticeable. So we could choose to leave the current logic acceptable as-is, although it would be good to have concrete down-side as reason for rejecting improved timer precision.
This PR introduces a high resolution timer into the main loop, although for now it should rarely be used except when timers are about to run (within 5ms).
WIN32's native API's for high resolution timing seem quite limited (see this Q&A + linked topics) and I'm not sure how std::this_thread::sleep_for is implemented internally on Windows. It may be that the C++ implementation has down-sides similar to the kinds of workarounds I found online (when looking into implementing a microsecond version of PIL_sleep_ms on WIN32).

When a timer needs to execute during the idle time (currently 5ms), use microsecond precision to ensure the timer isn't delayed by the idle time. This improves the precision of animation playback on systems that support it (WIN32, see note below). In my tests FPS playback varied: - 59.94 FPS would jitter between 58.13 & 63.11 FPS. - 23.98 FPS would jitter between 23.68 & 24.31 FPS. Using higher precision timers mostly resolves this issue although there is still some jitter although it's now limited to ~0.01 FPS. These values were measured with the FPS samples set to show real times between frames (without them being smoothed out). This is a continuation of a fix for #111579 which avoided the worst of the jittering issues at higher frame rates. It appears WIN32 doesn't support sleeping shorter than 1 millisecond via `std::this_thread::sleep_for`, making this change have no benefit on WIN32, from tests it also doesn't have any down sides, so avoid platform specific logic. The WIN32 limitation is noted in code-comments. If a method of higher precision method is available this can be investigated. ---- To reproduce this error, set the FPS samples preference to 1, use the default scene and play animation either at 59.94 or 23.98 FPS. Using a fractional FPS ensures a fractional FPS is displayed in the view-port. NOTES: - The FPS error is roughly between 2.6 - 8.6% with the higher errors occurring at higher FPS (59.94) in this case, where they're less likely to be noticeable. So we could choose to leave the current logic acceptable as-is, although it would be good to have concrete down-side as reason for rejecting improved timer precision. - This PR introduces a high resolution timer into the main loop, although for now it should rarely be used except when timers are about to run (within 5ms). - WIN32's native API's for high resolution timing seem quite limited (see this [Q&A](https://stackoverflow.com/questions/9116618) + linked topics) and I'm not sure how `std::this_thread::sleep_for` is implemented internally on Windows. It may be that the C++ implementation has down-sides similar to the kinds of workarounds I found online (when looking into implementing a microsecond version of `PIL_sleep_ms` on WIN32).

Campbell Barton requested review from Brecht Van Lommel 2023-08-28 10:14:28 +02:00

Campbell Barton requested review from Bastien Montagne 2023-08-28 10:14:38 +02:00

Campbell Barton requested review from Jacques Lucke 2023-08-28 10:14:53 +02:00

Campbell Barton commented

2023-08-28 10:41:04 +02:00

@blender-bot build

Bastien Montagne reviewed 2023-08-28 10:49:00 +02:00

Bastien Montagne left a comment

From code PoV, LGTM.

Have you tried it on a Windows machine? According to this thread e.g., it seems that Windows can have fairly longer times than requested with this call, wondering if it does stabilize the FPS on this OS?

From code PoV, LGTM. Have you tried it on a Windows machine? According to [this thread](https://stackoverflow.com/questions/54493041/unpredictable-behaviour-of-stdsleep-for-on-windows-10) e.g., it seems that Windows can have fairly longer times than requested with this call, wondering if it does stabilize the FPS on this OS?

Campbell Barton commented

2023-08-28 11:20:25 +02:00

@blender-bot package windows

Blender Bot commented

2023-08-28 11:20:29 +02:00

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR111603) when ready.

Campbell Barton commented

2023-08-28 11:24:47 +02:00

@mont29 no, I haven't tested on windows (set the build-bot to create a package).

It seems that this may not work well on windows - or may have higher CPU use.

We could either:

Disable high-resolution sleep on WIN32 if there are drawbacks we can't avoid.
Disable high-resolution sleep by default, but allow for certain timers (flag timers for e.g) and only use microsecond sleep for these (which could be used by animation playback). Although as this only impacts the moment before a timer runs, it might not be worth the increased complexity from having some timers behave differently from others.

@mont29 no, I haven't tested on windows (set the build-bot to create a package). It seems that this may not work well on windows - or may have higher CPU use. We could either: - Disable high-resolution sleep on WIN32 if there are drawbacks we can't avoid. - Disable high-resolution sleep by default, but allow for certain timers (flag timers for e.g) and only use microsecond sleep for these (which could be used by animation playback). Although as this only impacts the moment before a timer runs, it might not be worth the increased complexity from having some timers behave differently from others.

Campbell Barton commented

2023-08-29 01:31:29 +02:00

Testing on windows std::this_thread::sleep_for doesn't have any noticable advantage over PIL_sleep_ms comparing before/after side-by-side the frame-jitter - the problem was exactly the same.

For reference this was a low end laptop with a built in intel GPU, tested with small windows with a blank view-port:

Windows 10 22H2
Intel i5-7300, 2.60 GHZ.

Testing on windows `std::this_thread::sleep_for` doesn't have any noticable advantage over `PIL_sleep_ms` comparing before/after side-by-side the frame-jitter - the problem was exactly the same. For reference this was a low end laptop with a built in intel GPU, tested with small windows with a blank view-port: - Windows 10 22H2 - Intel i5-7300, 2.60 GHZ.

Campbell Barton commented

2023-08-29 01:44:41 +02:00

Made a test commit to check on spinning until sub 1ms timers are reached, I'm not especially keen on this but if the overall CPU usage isn't much higher it might be OK.

Update: this doesn't make any noticeable improvement either (nor does in result in noticeably higher CPU usage).

@blender-bot package windows

Made a test commit to check on spinning until sub 1ms timers are reached, I'm not especially keen on this but if the overall CPU usage isn't much higher it might be OK. Update: this doesn't make any noticeable improvement either (nor does in result in noticeably higher CPU usage). ---- @blender-bot package windows

Blender Bot commented

2023-08-29 01:44:45 +02:00

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR111603) when ready.

Campbell Barton force-pushed pr-high-precision-timers from f0f9364f74 to 74d0bb2e81

2023-08-29 02:41:50 +02:00

Compare

Campbell Barton force-pushed pr-high-precision-timers from 74d0bb2e81 to 6d2ea5435a

2023-08-29 02:50:40 +02:00

Compare

Campbell Barton force-pushed pr-high-precision-timers from 6d2ea5435a to 04dd7606db

2023-08-29 03:02:06 +02:00

Compare

Campbell Barton commented

2023-08-29 03:11:01 +02:00

Updated the PR to remove WIN32 ifdef's & the PR message to note that this change doesn't show noticeable improvements on WIN32.

While I'm less keen on this change given it doesn't solve timer precision on WIN32, it's also not great to limit macOS & Linux because of a limitation on WIN32.

We could also define this problem as a technical limitation that doesn't actually impact users, if the FPS playback is good enough from what the user can perceive, the fact the FPS display jitters, could be overlooked.

If others feel positively about this change I think it's OK to include but we could leave it as a known limitation too.

Updated the PR to remove WIN32 ifdef's & the PR message to note that this change doesn't show noticeable improvements on WIN32. While I'm less keen on this change given it doesn't solve timer precision on WIN32, it's also not great to limit macOS & Linux because of a limitation on WIN32. We could also define this problem as a technical limitation that doesn't actually impact users, if the FPS playback is good enough from what the user can perceive, the fact the FPS display jitters, could be overlooked. If others feel positively about this change I think it's OK to include but we could leave it as a known limitation too.

Campbell Barton referenced this pull request

2023-08-29 05:05:13 +02:00

Erratic viewport FPS at high frame rate #111579

Bastien Montagne approved these changes 2023-08-29 10:39:35 +02:00

Bastien Montagne left a comment

I think it's fine to improve Linux/OSX, even if Windows cannot benefit from this, the changes are not that big, and in the future maybe the windows std implementation will be better?

Could be worth keeping a task somewhere though about improving our timer precision on Windows.

I think it's fine to improve Linux/OSX, even if Windows cannot benefit from this, the changes are not that big, and in the future maybe the windows `std` implementation will be better? Could be worth keeping a task somewhere though about improving our timer precision on Windows.

Campbell Barton manually merged commit 745f78f9f0 into main

2023-08-30 05:05:41 +02:00

Campbell Barton deleted branch pr-high-precision-timers

2023-08-30 05:05:51 +02:00

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

WM: improve timer precision for more precise playback #111603