www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - High-resolution thread sleep

reply Ivan Trombley <itrombley dot-borg.org> writes:
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?
Dec 14 2017
parent reply Rene Zwanenburg <renezwanenburg gmail.com> writes:
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.
Dec 14 2017
parent reply Ivan Trombley <itrombley dot-borg.org> writes:
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);
}
Dec 14 2017
next sibling parent reply Rene Zwanenburg <renezwanenburg gmail.com> writes:
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 ;)
Dec 14 2017
parent Ivan Trombley <itrombley dot-borg.org> writes:
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.  
:)
Dec 14 2017
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Dec 14 2017
parent reply Rene Zwanenburg <renezwanenburg gmail.com> writes:
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.
Dec 15 2017
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Dec 15 2017