Hi im having some weird timing issues on win7. I dont have win7 my self so cant really find the issue that easily.
All os’es are welcome to test it.
It is a small app that blinks text on the screen after specific intervals and thats it.
I would really appriciate if you could run it on your computer and post if it behaved as expected or not,
I can’t test it because I’m at school, so no browser plugin or even Panda3D installed, however I think that maybe the computer with Win7 that you or someone else tested on might not have hardware acceleration, maybe they didn’t install there graphics drivers. Anyway I think it may be a problem specific to that computer.
So possibly the task is lagging, what you could do to test this is put a timer on screen to see if time is passing at an appropriate speed, to see if its lagging. Also it wouldn’t hurt to do profiling if thats the case to see where the problem is occurring. Check this link for more on profiling, http://docs.python.org/library/profile.html
If you have python on the computer pstat, profiler and cProfile come with the python interpreter, you just have to program it into your code and watch the terminal or write it to a log file to see where the bottleneck/lag occurs.
As far as time.clock goes, it should behave similarly in windows and linux: just the resolution might change a tad. Besides, time.time is not guaranteed to have <1s resolution while time.clock is.
At the end of the day it might be easier to use intervals or panda’s globalClock.getDt()/globalClock.getFrameTime() as panda ensures that these will operate identically on all platforms as best it can.
What you could do is import os and use different timers for different OS’s, just make a wrapper of time.time and time.clock, and if it detects windows use time.clock otherwise use time.time, that seems to be a reasonable solution in this case.
You would think P3D would be more portable, so theres probably a better fix, however I’m not certain.
The absolute time returned by time.clock changes based upon os, but the relative time difference is the same (I think xp has slightly less resolution than everything else, but this doesn’t affect it) across all OS’s. In fact, time.clock is python’s preferred way of measuring relative time. Unless your trying to do something like a calandar, time.clock is gauranteed by python to work across all os’s while time.time can change.
As for why panda screws up time.time, it appears that loading opengl/directx is forcing single precision mode which in windows prevents time.time from returning enough sig figs to see the difference–and the code that handles time.time continually gets a dt of 0 and hence never can actually change.
Exactly right. This depends on your graphics driver, by the way, which is why some people are seeing it and some aren’t.
In any case, for this reason we suggest not using time.time() in your Panda application. You can use time.clock(), as suggested; but globalClock.getFrameTime() is usually the best choice for performing time-based operations, because it’s the clock that Panda’s internal operations are also using.