for some animations, I want to create 50 frames per second.
So I use the wx.Timer to generate an event, on which the animation is changed.
The program works perfect under Linux (Fedora, Ubuntu),
but doesn't run fluently in the same test machines under winXP-SP2.
I measured the time between the animated pictures,
and it varies (most of the time) between 2 values: 15 and 30 msec,
maybe even with an average of 20 msec.
Apparently the wx.Timer works with the 15 msec windows clocktick ??
Has anyone ever used a high resolution timer in wxPython,
that works well under Linux / Windows ( Mac) ?
for some animations, I want to create 50 frames per second.
So I use the wx.Timer to generate an event, on which the animation is
changed.
The program works perfect under Linux (Fedora, Ubuntu),
but doesn't run fluently in the same test machines under winXP-SP2.
I measured the time between the animated pictures,
and it varies (most of the time) between 2 values: 15 and 30 msec,
maybe even with an average of 20 msec.
Apparently the wx.Timer works with the 15 msec windows clocktick ??
Has anyone ever used a high resolution timer in wxPython,
that works well under Linux / Windows ( Mac) ?
I got into a problem with wxTimer when I was doing a timing
program for behavioral data. I switched to just using the Python
time module and making a time stamp at start time, another at
end time, and then subtracting them for the duration. There is
also the Python TImer http://www.python.org/doc/2.5.2/lib/timer-objects.html
···
On Fri, Oct 31, 2008 at 5:14 PM, Stef Mientki <s.mientki@ru.nl> wrote:
I must be tireder than I realized; re-reading your email tells me
the timestamp method won't help you. Maybe the Python timer
then.
···
On Fri, Oct 31, 2008 at 6:31 PM, C M <cmpython@gmail.com> wrote:
On Fri, Oct 31, 2008 at 5:14 PM, Stef Mientki <s.mientki@ru.nl> wrote:
hello,
for some animations, I want to create 50 frames per second.
So I use the wx.Timer to generate an event, on which the animation is
changed.
The program works perfect under Linux (Fedora, Ubuntu),
but doesn't run fluently in the same test machines under winXP-SP2.
I measured the time between the animated pictures,
and it varies (most of the time) between 2 values: 15 and 30 msec,
maybe even with an average of 20 msec.
Apparently the wx.Timer works with the 15 msec windows clocktick ??
Has anyone ever used a high resolution timer in wxPython,
that works well under Linux / Windows ( Mac) ?
I got into a problem with wxTimer when I was doing a timing
program for behavioral data. I switched to just using the Python
time module and making a time stamp at start time, another at
end time, and then subtracting them for the duration. There is
also the Python TImer http://www.python.org/doc/2.5.2/lib/timer-objects.html
for some animations, I want to create 50 frames per second.
So I use the wx.Timer to generate an event, on which the animation is changed.
The program works perfect under Linux (Fedora, Ubuntu),
but doesn't run fluently in the same test machines under winXP-SP2.
When you say it doesn't run fluently, what exactly happens? Does it appear sluggish? Flicker?
I measured the time between the animated pictures,
and it varies (most of the time) between 2 values: 15 and 30 msec,
maybe even with an average of 20 msec.
Apparently the wx.Timer works with the 15 msec windows clocktick ??
Has anyone ever used a high resolution timer in wxPython,
that works well under Linux / Windows ( Mac) ?
The timer itself is not a very heavyweight object. I think it does have a lower limit of about 10ms, but even that can fire 100 times each second, which is more than enough fps for pretty much anything. Usually, when a timer is not firing as fast as it's supposed to, it's not the timer itself that is at fault; it's because timer events are getting jammed up by heavy paint routines that are sucking CPU time. If you haven't already, you may want to actually try measuring how long your paint event handler takes to run using the time module or something like hotshot, because if your paint code is too slow to handle 50 fps on Win, it won't matter how often your timer fires.
Also, if you're using wxGraphicsContext to draw, it's important to note that it is NOT hardware accelerated under Windows, but is on Linux, so that could cause some slowness specific to Windows.
for some animations, I want to create 50 frames per second.
So I use the wx.Timer to generate an event, on which the animation is changed.
The program works perfect under Linux (Fedora, Ubuntu),
but doesn't run fluently in the same test machines under winXP-SP2.
When you say it doesn't run fluently, what exactly happens? Does it appear sluggish? Flicker?
I did some further testing,
and maybe the problem is not as big as I thought
(although I still would like to have a high-resolution timer
I can easily draw 200 frames per second (what ever value that has), and then it consumes just 20% of my processor time.
but it's not equidistant, if I log the time between wx.Timer events, I get in this case : 0,0,0,15,0,0
so indeed an average of about 5 msec.
In Linux on the same machine I get 5,5,5,5,4,5,5,6, which is (almost) equidistant.
I noticed another important disturbance: aliasing.
After switching to anti-aliasing the animation looked much better.
So probably in this case the solution is satisfying.
thanks,
Stef
···
On Oct 31, 2008, at 2:14 PM, Stef Mientki wrote:
I measured the time between the animated pictures,
and it varies (most of the time) between 2 values: 15 and 30 msec,
maybe even with an average of 20 msec.
Apparently the wx.Timer works with the 15 msec windows clocktick ??
Has anyone ever used a high resolution timer in wxPython,
that works well under Linux / Windows ( Mac) ?
The timer itself is not a very heavyweight object. I think it does have a lower limit of about 10ms, but even that can fire 100 times each second, which is more than enough fps for pretty much anything. Usually, when a timer is not firing as fast as it's supposed to, it's not the timer itself that is at fault; it's because timer events are getting jammed up by heavy paint routines that are sucking CPU time. If you haven't already, you may want to actually try measuring how long your paint event handler takes to run using the time module or something like hotshot, because if your paint code is too slow to handle 50 fps on Win, it won't matter how often your timer fires.
Also, if you're using wxGraphicsContext to draw, it's important to note that it is NOT hardware accelerated under Windows, but is on Linux, so that could cause some slowness specific to Windows.
