Timing issues (win7 i think)

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,

Please also test the p3d version in browser:

something like that:
winXp, blinked just fine
win7, a lot slower than it should

Thank you very much

# -*- coding: utf-8 -*-
import direct.directbase.DirectStart
from direct.showbase.DirectObject import DirectObject
from pandac.PandaModules import PandaNode,TextNode,NodePath
import sys,time

class Showoff(DirectObject):
    def __init__(self):                
        self.accept('bdown', self.buttons,[True])
        self.accept('bup', self.buttons,[False])         
    def buttons(self,tag,but):
        if tag:
            if but=='escape':
            elif but=='1':
            elif but=='2':
            elif but=='3':
    def addtext(self,txt,tdif):
        if txt:
        return textnode
    def run(self,task):
        for tx in self.txts:
            if dd>tx[1]:
        return task.cont

tt=so.addtext('0.5 sec tick',0.5)
tt=so.addtext('1 sec tick',1)
tt=so.addtext('5 sec tick',5)
tt=so.addtext('0.1 Press ESC to exit',0.1)


Win7 x64 Pro -> No blinking at all

same with the p3d in chrome browser

Ok,thank you, now the only question is can someone who is technical enough figure out why does not win7 (maybe only 64bit) like the above code.

Works and looks fine for me… windows 7 64bit Pro.

Can’t test chrome tho… sorry.

Oh crap, just got a successful test on win7 64bit,
so now there 2 successful runs.
Bite me whtas the issue :frowning:

I tested the:
at work on a :
win7 enterprise 64bit
6.1.7600 build 7600

no blinking

no blinking


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

ov3rcl0ck, you are so far correct, my computer at work does not have a hardware acceleration, it has a built in graphics card that is rather bad.

Now if thats the case then i really hope that someone from panda can point me to a solution.

Cant really run the profiling test at work, im really not allowed to install non approved soft on my computer, not even the panda3d runtime(dont tell that i did ;P)

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.

my computer has hardware acceleration, and as you can see in my earlier post -> no blinking.

newest drivers are installed.


i tested the code on my laptop (Win XP Pro 32bit, intel integrated graphics) -> works fine

It works completely fine for me (i have win7). it might have to do with certain OS’es versions of certain browsers.

So far it seems the browser is not the issue, but it seems to be win7 or hardware related.

Well, it certainly isn’t win7, as my computer uses it and it works fine.

it appears as if it is a problem with windows reporting time.time correctly in certain cases (32 bit python on 64 bit win7 perhaps??)

time.time returns a constant for me on win7, but by replacing all instances of time.time with time.clock I got the example working.

Yet time.clock behaves differently on linux.

I know many ways how to make a time counter the other way, but im rather interested in why time.time() under panda3d is not working properly(it works well if you run python only applications)

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.

Yes i plant to rewrite the time thigys on top of gobalClock.getRealTime().
But still i hope the time.time() stuff gets solved/cleared.

Time.clock() on linux measures the time the proecces has run(that means only the time it took the process to run, it will not show the time since process started)

On winXp time.clock behaves very similar just with a different precision.

On win7(the problematic hardvare version) time.clock() does the same lagg(it counts only time that the process run)

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.