Capturing tablet data at constant rate, instead of at frame rate (python, pygame, wintab, cgkit)

Question

First of all, I am not a veteran programmer i any language. But I've been tinkering with python pretty substantially the last couple of months so I wouldn't consider my self completely green either.

Some keywords for you:
- Windows
- Python 2.6
- Pygame, CGKit

Okay, so I've got the CGKit module, which contains a WinTab wrapper for capturing data from the Wacom tablet. WinTab requires a certain window to be active in order for it to start capturing, and for that I'm using PyGame. However, PyGame is pretty brutal on the CPU and gives me between 100-200 fps on drawing simple text and rectangles (meters for the wacom input data.) and about 200-400 fps when not 'blitting' anything.

Now, the tablet hardware, and the WinTab API support a transfer rate of 200hz, which is all good. The problem is that the data I'm getting from WinTab isn't at 200hz (5ms per packet) but is instead at the current framerate of my PyGame window, which, on top of everything, is not static.

So you see the problem. In order for WinTab to acquire any data, it has to have a window assigned to it and it need to be 'active'. But having a PyGame window open, means that the stream of data is limited to the framerate of the pygame window.

I'm sure there are other window managers I could be using that won't take up any or little CPU, but what I'd really like is for WinTab to acquire the data at constant 200hz rate without any dependencies.

I'm thinking threading. Breaking up the gather-data and drawing parts, but since WinTab need a window to get any data in the first place, I can't figure out how that would be possible.

Also note that I've never threaded anything before, although I do understand the concept.

So, hope I made the problem reasonably clear.

The question is, how can I get the data at a minimum of 200hz, while still being able to do maybe 20-30 fps on my PyGame window?

Answer 1

without being experienced on the subject, I would say that threads are not a good idea for precise timing functions. From what I studied there is not a precise timing enforced on them .

I remember there is a function inside the time pygame module that forces your code to run at a specific time and thus limits the FPS. That is for if your code runs too fast.

Now if your app is proving too slow for the 200Mhz rate, that is it takes more than 5ms to loop then you will have to move some of your code to C/C++ domain and avoid using pygame for at least that part. I advice using cython , since cython allow you to write only python code and you dont need to know C/C++. But of course you can mix python with C/C++ and even Fortran with cython, its extremely flexible and easy to use.

Cython Website

My experience with pygame on an Atom 1,6 processor , which is of course very slow, gave me 1 ms for zero redraws, so pygame can be really fast but not blazzing fast. It will highly depend on what you draw in the screen during your loop. I would guess that on a core duo that 1 ms should drop to at least 0.3 ms. So it will also depend on your processing speed.

Another approach is the multiprocessing module, which it can take full avantage of multiple cores and assign one core for your app and another core for receiving data from the tablet.

Multiprocessing module documentation

There are literally hundrends of ways to speed up python.