• nobody_ (8/8) Nov 15 2006 How do I make a thread run at a certain rate (x times a second ) without...
• Alexander Panek (10/23) Nov 15 2006 Does the output really have to be with 50Hz, or do you simply want to
• Bill Baxter (9/35) Nov 16 2006 You probably need to be more specific about what you plan to use for
• Mike Parker (15/26) Nov 16 2006 I don't want to hijack the thread, but that's not what glfwSwapInterval
• Mike Parker (9/22) Nov 16 2006 I don't know what sort of application you want this for, but in
• nobody_ (10/18) Nov 18 2006 Sorry for my late reply (unexpected stuff :(
• Jarrett Billingsley (12/22) Nov 18 2006 Do you *absolutely* need 1000 updates per second? What are you doing th...
• nobody_ (8/18) Nov 18 2006 Hyperthreading and dual core systems can handle this, right?
• Georg Wrede (7/12) Nov 18 2006 You'd have some serious explaining to do before you can convince me that...
• nobody_ (11/17) Nov 18 2006 Lol, I would rather have a discussion about the threading...
• Paolo Invernizzi (5/13) Nov 21 2006 Well, there's only one company I know that HAS a 1k/hz eyetracker ;-)
• nobody_ (1/1) Nov 21 2006 http://www.fourward.com/
• Lutger (4/8) Nov 19 2006 Correct me if I'm wrong, but from what I've gathered about timing you
• nobody_ (4/7) Nov 19 2006 There are alot of microseconds in a millisecond ;)

"nobody_" <spam spam.spam> writes:

How do I make a thread run at a certain rate (x times a second ) without 
bothering the rest of the program?

The main-loop runs at about 1000hz and I need to output some of the data to 
my screen at about 50/60Hz.
I don't care whether there are frames lost, as long as the main loop runs 
correctly.

Or shouldn't I use a seperate thread for the screenoutput?

Thx 

Alexander Panek <a.panek brainsware.org> writes:

Does the output really have to be with 50Hz, or do you simply want to 
trigger output with a frequency of 50Hz? You could start a thread 
everytime that puts that stuff onto the screen, while your main loop 
just continues.

Apart from that you could also use a seperate thread that outputs a 
stack that is filled up by your main routine.

How exactly do you ensure that your main routine runs with ~1kHz? Sounds 
quite need-to-hack-timer-interrupt-ish :P .

Alex

nobody_ wrote:
 How do I make a thread run at a certain rate (x times a second ) without 
 bothering the rest of the program?
 
 The main-loop runs at about 1000hz and I need to output some of the data to 
 my screen at about 50/60Hz.
 I don't care whether there are frames lost, as long as the main loop runs 
 correctly.
 
 Or shouldn't I use a seperate thread for the screenoutput?
 
 Thx 
 
 

Bill Baxter <dnewsgroup billbaxter.com> writes:

Alexander Panek wrote:
 Does the output really have to be with 50Hz, or do you simply want to 
 trigger output with a frequency of 50Hz? You could start a thread 
 everytime that puts that stuff onto the screen, while your main loop 
 just continues.
 
 Apart from that you could also use a seperate thread that outputs a 
 stack that is filled up by your main routine.
 
 How exactly do you ensure that your main routine runs with ~1kHz? Sounds 
 quite need-to-hack-timer-interrupt-ish :P .
 
 Alex
 
 nobody_ wrote:
 How do I make a thread run at a certain rate (x times a second ) 
 without bothering the rest of the program?

 The main-loop runs at about 1000hz and I need to output some of the 
 data to my screen at about 50/60Hz.
 I don't care whether there are frames lost, as long as the main loop 
 runs correctly.

 Or shouldn't I use a seperate thread for the screenoutput?

 Thx


You probably need to be more specific about what you plan to use for 
drawing the output, because different libraries have different ways to 
achieve what you want.  For instance GLFW has a function 
"glfwSwapInterval()" to which you can pass the desired frame rate of 
your rendering.  Internally it presumably has some sort of timer and 
sleep call for suspending itself between renders.  I think SDL also has 
something like that.

--bb

Mike Parker <aldacron71 yahoo.com> writes:

Bill Baxter wrote:



 
 You probably need to be more specific about what you plan to use for 
 drawing the output, because different libraries have different ways to 
 achieve what you want.  For instance GLFW has a function 
 "glfwSwapInterval()" to which you can pass the desired frame rate of 
 your rendering.  Internally it presumably has some sort of timer and 
 sleep call for suspending itself between renders.  I think SDL also has 
 something like that.
 
 --bb

I don't want to hijack the thread, but that's not what glfwSwapInterval 
is for, Bill. What it does is to either turn vsync off (an arg of 0) or 
on (an arg of 1 or higher), vsync being the vertical retrace (i.e. the 
updating of the screen, scan line by scan line, from top to bottom). 
Passing an arg of 1 will wait for one whole vertical retrace to complete 
before updating the screen again. The speed of the retrace is determined 
by the current display mode's refresh rate (60hz, 80hz, or whatever). 
Calling glfwSwapInterval with a value of 1 will effectively cap the 
frame rate to the refresh rate (i.e. a 60hz refresh rate will cap at 60 
fps), but it is not the same as running a rendering loop at 60hz per 
second. If you want to specify a frame rate lower than the refresh rate, 
the rendering loop will need to be managed manually to achieve it.

On Windows, glfwSwapInterval is a wrapper for a WGL extension. On other 
platforms, it may not work at all.

Mike Parker <aldacron71 yahoo.com> writes:

nobody_ wrote:
 How do I make a thread run at a certain rate (x times a second ) without 
 bothering the rest of the program?
 
 The main-loop runs at about 1000hz and I need to output some of the data to 
 my screen at about 50/60Hz.
 I don't care whether there are frames lost, as long as the main loop runs 
 correctly.
 
 Or shouldn't I use a seperate thread for the screenoutput?
 
 Thx 
 
 

I don't know what sort of application you want this for, but in 
principle it sounds very much like a typical game loop. Using a separate 
thread for constant update isn't likely not a good strategy. This 
article describes how to separate logic UPS (updates per second) from 
rendering FPS (frames per second):

http://users.telenet.be/dewitters/gameloop.html

Following that technique, you should be able to keep your 1000hz loop 
and have your 60hz display updates all in one thread.

"nobody_" <spam spam.spam> writes:

 I don't know what sort of application you want this for, but in principle 
 it sounds very much like a typical game loop. Using a separate thread for 
 constant update isn't likely not a good strategy. This article describes 
 how to separate logic UPS (updates per second) from rendering FPS (frames 
 per second):

 http://users.telenet.be/dewitters/gameloop.html

 Following that technique, you should be able to keep your 1000hz loop and 
 have your 60hz display updates all in one thread.

Sorry for my late reply (unexpected stuff :(

Won't I get into trouble when I keep everything in one thread and a 
screen-update takes longer than one millisecond?
That way I could lose a loop and I really need all 1000 of them at the 
correct time.

I thought that if I were to put the gfx in a different thread I could 
guarantee my mainloop.
making the gfx thread idle and having some kind of thread-sleep of 20ms 
every loop.

Or am I just being naive :) 

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"nobody_" <spam spam.spam> wrote in message 
news:ejns1i$2nnk$1 digitaldaemon.com...

 Sorry for my late reply (unexpected stuff :(

 Won't I get into trouble when I keep everything in one thread and a 
 screen-update takes longer than one millisecond?
 That way I could lose a loop and I really need all 1000 of them at the 
 correct time.

Do you *absolutely* need 1000 updates per second?  What are you doing that 
requires such precise timing?

 I thought that if I were to put the gfx in a different thread I could 
 guarantee my mainloop.
 making the gfx thread idle and having some kind of thread-sleep of 20ms 
 every loop.

 Or am I just being naive :)

Keep in mind that even though you're using multiple threads, your code won't 
run any faster.  You've still got the same amount of processing power.  So 
if your logic loop can't keep up with the graphics in a single-threaded 
program, it won't be able to in a multi-threaded program either.  What you'd 
basically end up doing is having the graphics thread wait for the logic 
thread to finish its update, and they'd operate in lock step - at which 
point you're doing pretty much the same thing as having a single-threaded 
program. 

"nobody_" <spam spam.spam> writes:

 Do you *absolutely* need 1000 updates per second?  What are you doing that 
 requires such precise timing?

Yep, eyetracking :)

 Keep in mind that even though you're using multiple threads, your code 
 won't run any faster.  You've still got the same amount of processing 
 power.  So if your logic loop can't keep up with the graphics in a 
 single-threaded program, it won't be able to in a multi-threaded program 
 either.  What you'd basically end up doing is having the graphics thread 
 wait for the logic thread to finish its update, and they'd operate in lock 
 step - at which point you're doing pretty much the same thing as having a 
 single-threaded program.

Hyperthreading and dual core systems can handle this, right?

But first try to get it to work on a single core system :)

Lets asume I have a seperate thread for my gfx, in which I plot a hundred 
pixels(idle) (no swapping/buffering)
Will this loop(of pixel putting) never be interrupted by the main 
loop(critical)?
If this is the case, then I should just do some fancy stuff in one loop :)

Georg Wrede <georg.wrede nospam.org> writes:

nobody_ wrote:
Do you *absolutely* need 1000 updates per second?  What are you doing that 
requires such precise timing?

 
 
 Yep, eyetracking :)

You'd have some serious explaining to do before you can convince me that 
there is an actual need for more than 25 u/s for eye tracking.

Supposing the viewer is looking at a CRT that updates at like 120Hz, 
then it would be convenient to do the eye tracking at that frequency. 
That would be ample for the eye tracking itself, and also pretty 
convenient with regards to getting a tracking value for each video frame.

"nobody_" <spam spam.spam> writes:

Lol, I would rather have a discussion about the threading...

The position on the screen isn't the only interesting part ;)
Think for instance about acceleration and microsaccades.
Plus you need at least twice the frequency af the actual wave you are trying 
to measure.

Well I think thats enough about the eye.
So..
Can a thread be interrupted in the middle?
I think the awnser is yes, thus making a second thread for the graphics a 
good idea.
(my second post is a bit more clear I think :)



 You'd have some serious explaining to do before you can convince me that 
 there is an actual need for more than 25 u/s for eye tracking.

 Supposing the viewer is looking at a CRT that updates at like 120Hz, then 
 it would be convenient to do the eye tracking at that frequency. That 
 would be ample for the eye tracking itself, and also pretty convenient 
 with regards to getting a tracking value for each video frame. 

Paolo Invernizzi <arathorn NOSPAM_fastwebnet.it> writes:

Well, there's only one company I know that HAS a 1k/hz eyetracker ;-)
BUT 50/60 hz are pretty common...

--
Paolo Invernizzi

nobody_ wrote:
 Lol, I would rather have a discussion about the threading...
 
 The position on the screen isn't the only interesting part ;)
 Think for instance about acceleration and microsaccades.
 Plus you need at least twice the frequency af the actual wave you are trying 
 to measure.
 
 Well I think thats enough about the eye.

"nobody_" <spam spam.spam> writes:

http://www.fourward.com/

Lutger <lutger.blijdestijn gmail.com> writes:

nobody_ wrote:
 Do you *absolutely* need 1000 updates per second?  What are you doing that 
 requires such precise timing?

 
 Yep, eyetracking :)

Correct me if I'm wrong, but from what I've gathered about timing you 
can't have any such guarantees about getting 1ms updates on a 
non-realtime OS (such as windows xp), with or without threading.

"nobody_" <spam spam.spam> writes:

 Correct me if I'm wrong, but from what I've gathered about timing you 
 can't have any such guarantees about getting 1ms updates on a non-realtime 
 OS (such as windows xp), with or without threading.

There are alot of microseconds in a millisecond ;)
If you do countperiod/microseconds and get lucky you even get your cpuspeed.

Remove as many services as possible and its possible to get really close to 
realtime at a millisecond level.