Re: [AD] Add timeBeginPeriod(1) to wtimer.c

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


i looked at the src code, to find out about the WaitForSingleObject()

how do you measure the results ?

lets presume for a moment that the theory about the kernel running more often to check on this thing is going to cost CPU cycles, what if it does! i mean is the .001% really going to matter ?

now lets presume the WaitForSingleObject() gets checked whenever the CPU
is ready to check it, it will get done when it gets done. which is how i think it actaully works. if i request 1ms resolution, i *mean* i want
1ms resolution.  not some random number between 6 and 12ms.

does the continual calling of timeBeginPeriod()/End() going to cost more than just setting it once, and leaving it ?

how varied is your performance when using this mod ?

i set it in my main(), and leave it set.

aj.






Tobias Scheuer wrote:
I think you're right. But my measurements have given different results,
though I can't explain all the details. It might also depend on the machine
and graphics adapter. Did you try the change on Windows on your PC?


allegro uses timeGetTime() in its low_perf_thread which would be effected, but in my opinion, a good way. it uses a WaitForSingleObject() which will signal when the time is right regardless of how much resoltuion was used to set the time. i dont see how it can be effecting anything, if anything, it should be making everything more responsive.

aj.



Tobias Scheuer wrote:

I think it affects the timers more generally, so it also affects the

timers

in allegro's separate timer threads. Didn't go into all the details, and

I

don't have a decent profiler at home, so I couldn't find out where

exactly

the slowdown comes from. Maybe I should try to Quantify this at work...


it changes the resolution of the rest() and timeGetTime() but it doesn't slow down the app itself.
how could it ?



Tobias Scheuer wrote:


I have tried that. The documentation says that each call to

timeBeginPeriod


has to be matched by a call to timeEndPeriod, so that#s why I have also
called that function. If I leave that out, the timeBeginPeriod(1)

remains


active, which causes some overall slowdown of the whole program (as
mentioned in the forum).



timeBeginPeriod only needs to be called once for the whole process.
not each time rest is called.






Hi all,

as already discussed in the forum, I would propose to change the

current


implementation of tim_win32_rest in wtimer.c to the following:

[code]
/* tim_win32_rest:
*  Rests the specified amount of milliseconds.
*/
static void tim_win32_rest(unsigned int time, AL_METHOD(void,

callback,

(void)))
{
unsigned int start;
unsigned int ms = time;

const MMRESULT rc = timeBeginPeriod(1);
if (callback) {
   start = timeGetTime();
   while (timeGetTime() - start < ms)
      (*callback)();
}
else {
   Sleep(ms);
}
if( rc == TIMERR_NOERROR )
  timeEndPeriod(1);
}
[/code]

The new lines are the call to timeBeginPeriod(1); and the correcponding call
to timeEndPeriod(1); in case the first call was successful.

This affects only windows, and increases the accuracy of calls to rest(n).

For the discussions, refer to the following threads:

http://www.allegro.cc/forums/view_thread.php?_id=456146
http://www.allegro.cc/forums/view_thread.php?_id=453116

As this is my very first contribution, please forgive if anything is not in
the right format or otherwise unexpected.

Thanks for consideration!

Best regards Tobias

--




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/