I need to be able to put a thread to sleep for some amount of time. I was looking at using Thread.sleep but it appears that on Windows, it's limited to millisecond resolution. Is there a way to do this in a cross-platform way that is higher resolution?

On Thursday, 14 December 2017 at 21:11:34 UTC, Ivan Trombley wrote:
> I need to be able to put a thread to sleep for some amount of time. I was looking at using Thread.sleep but it appears that on Windows, it's limited to millisecond resolution. Is there a way to do this in a cross-platform way that is higher resolution?

Sleeping for very short periods is usually a bad idea for various reasons. What do you need it for?

If you really need this, go for a loop with a high resolution timer.

On Thursday, 14 December 2017 at 21:47:05 UTC, Rene Zwanenburg wrote:
> On Thursday, 14 December 2017 at 21:11:34 UTC, Ivan Trombley wrote:
>> I need to be able to put a thread to sleep for some amount of time. I was looking at using Thread.sleep but it appears that on Windows, it's limited to millisecond resolution. Is there a way to do this in a cross-platform way that is higher resolution?
>
> Sleeping for very short periods is usually a bad idea for various reasons. What do you need it for?
>
> If you really need this, go for a loop with a high resolution timer.

Something along the lines of this:

while (render)
{
  immutable auto startTime = MonoTime.currTime;

  // Render the frame...

  immutable auto remain = m_frameDuration - (startTime - MonoTime.currTime);
  if (remain > Duration.zero)
    Thread.sleep(remain);
}

On Thursday, 14 December 2017 at 23:45:18 UTC, Ivan Trombley wrote:
> Something along the lines of this:
>
> while (render)
> {
>   immutable auto startTime = MonoTime.currTime;
>
>   // Render the frame...
>
>   immutable auto remain = m_frameDuration - (startTime - MonoTime.currTime);
>   if (remain > Duration.zero)
>     Thread.sleep(remain);
> }

In that case, the best thing you can do is use vsync as the waiting mechanism ;)

On Friday, 15 December 2017 at 00:39:13 UTC, Rene Zwanenburg wrote:
> On Thursday, 14 December 2017 at 23:45:18 UTC, Ivan Trombley wrote:
>> Something along the lines of this:
>>
>> while (render)
>> {
>>   immutable auto startTime = MonoTime.currTime;
>>
>>   // Render the frame...
>>
>>   immutable auto remain = m_frameDuration - (startTime - MonoTime.currTime);
>>   if (remain > Duration.zero)
>>     Thread.sleep(remain);
>> }
>
> In that case, the best thing you can do is use vsync as the waiting mechanism ;)

You know, you're right. I'm over-thinking this. Keep it simple.  :)

On 12/14/17 6:45 PM, Ivan Trombley wrote:
> On Thursday, 14 December 2017 at 21:47:05 UTC, Rene Zwanenburg wrote:
>> On Thursday, 14 December 2017 at 21:11:34 UTC, Ivan Trombley wrote:
>>> I need to be able to put a thread to sleep for some amount of time. I was looking at using Thread.sleep but it appears that on Windows, it's limited to millisecond resolution. Is there a way to do this in a cross-platform way that is higher resolution?
>>
>> Sleeping for very short periods is usually a bad idea for various reasons. What do you need it for?
>>
>> If you really need this, go for a loop with a high resolution timer.
> 
> Something along the lines of this:
> 
> while (render)
> {
>    immutable auto startTime = MonoTime.currTime;
> 
>    // Render the frame...
> 
>    immutable auto remain = m_frameDuration - (startTime - MonoTime.currTime);
>    if (remain > Duration.zero)
>      Thread.sleep(remain);
> }
> 

So... you plan on rendering more than 1000 frames per second?

I think in any case, even if the API allows it, you are probably not getting much better resolution on your non-windows systems.

Have you tried it anyway and see how it works? I think it might actually work just fine.

-Steve

On Friday, 15 December 2017 at 01:49:56 UTC, Steven Schveighoffer wrote:
>
> So... you plan on rendering more than 1000 frames per second?
>
> I think in any case, even if the API allows it, you are probably not getting much better resolution on your non-windows systems.
>
> Have you tried it anyway and see how it works? I think it might actually work just fine.
>
> -Steve

The higher precision would be needed b/c updating and rendering takes time, so the sleep time would be timePerFrame - timeSpendOnRendering.

Problem is you'll need vsync anyway to avoid tearing. Applications that use their own timing to limit the framerate without using vsync are easy to recognise: they have a tear slowly moving around on the screen. It's visually even more annoying than regular tearing.

On 12/15/17 5:43 AM, Rene Zwanenburg wrote:
> On Friday, 15 December 2017 at 01:49:56 UTC, Steven Schveighoffer wrote:
>>
>> So... you plan on rendering more than 1000 frames per second?
>>
>> I think in any case, even if the API allows it, you are probably not getting much better resolution on your non-windows systems.
>>
>> Have you tried it anyway and see how it works? I think it might actually work just fine.
>>
> 
> The higher precision would be needed b/c updating and rendering takes time, so the sleep time would be timePerFrame - timeSpendOnRendering.

And this would be sub-millisecond? Even at 120Hz framerate, that's 8ms per frame to render and display. If your margin for error is less than 1ms, then I think you shouldn't be sleeping :)

> Problem is you'll need vsync anyway to avoid tearing. Applications that use their own timing to limit the framerate without using vsync are easy to recognise: they have a tear slowly moving around on the screen. It's visually even more annoying than regular tearing.

OK. I'm not steeped in graphics development. It just seemed odd to me that millisecond resolution isn't fine enough. Clearly better sleep mechanisms wouldn't be the solution anyway!

-Steve