Hi Guys Vsync (or even the max fps with vsync off) blocks as soon as I try to flip() at more than 60Hz (or the max fps). When I set my flipping at 50Hz (with time.time()-last_flip_time >= 0.02 calls), it seems fine and I can go through my while loop at ridiculous speeds. I like the manual sleeping though, and in fact I thought of this after posting, and found the ctypes calls to utime and win32 high-res clocks calls which I copied into my code. I'll see if I can use pyglet's call for that instead so I don't have to have platform dependent code in my application. I think I'll go the multiprocess route to poll my device, thanks for that. I was wondering though, is there any way to use multiprocess to poll for keyboard events, so I essentially decouple drawing/flipping from keyboard event detection?
Thanks a ton, Prantik On Fri, Jan 22, 2010 at 12:19 PM, Casey Duncan <[email protected]>wrote: > I'm assuming here that window.flip() blocks with vsync on, which may > well not be true. If it doesn't block then I would try adding clock > sleeps to minimize CPU instead of threads or processes. > > -Casey > > On Fri, Jan 22, 2010 at 10:16 AM, Casey Duncan <[email protected]> > wrote: > > If you don't want to go the C route, this seems like a good > > opportunity to use the multiprocessing module (new in 2.6). With that > > you can setup a process to poll your external data source and put it > > in a queue to feed the process that draws to the screen. > > > > Also, another thought would be to just use you original method and try > > to minimize the CPU used. If you instantiate your own > > pyglet.clock.Clock() you can use its high-res sleep() method to rest > > the CPU in your polling loop for short intervals. The trouble with > > this is that with vsync on, your polling loop may skip some cycles > > while waiting for the window to flip(), depending on the timing. This > > shouldn't be a problem with the first solution, then you only have to > > worry about OS scheduling irregularities. > > > > -Casey > > > > On Fri, Jan 22, 2010 at 3:36 AM, Florian Bösch <[email protected]> wrote: > >> That's one of those typical I/O problems where I'd go and spawn a > >> thread in which I'd call a C function which operates a while loop at > >> 1khz and sleeps inbetween, then pushes its results to an output queue. > >> > >> On Jan 19, 4:52 am, Prantik <[email protected]> wrote: > >>> Hi there, > >>> > >>> I have some external experimental hardware providing data to my pyglet > >>> app in real-time (device access with ctypes), and it'd like to poll it > >>> for data at 1000Hz. Currently, my implementation is with a while loop > >>> in __main__ and manual ticks and flips, which works great, but of > >>> course thrashes CPU. I just need it to run at 1KHz, but my while loop > >>> runs at 600KHz, with each iteration checking my hardware for new data. > >>> I'm managing my ticks and framerate with time.time() to get a very > >>> nice constant 30.00 fps from the HUD meter. > >>> > >>> To try to get this speed and CPU util down to something between 1 & > >>> 10KHz, I've tried implementing this with the standard schedule and > >>> app.run() framework, but my problem is that schedule_interval has > >>> resolution only as good as my framerate, which is 60Hz max with vsync > >>> on and 500Hz with it off (i.e. fullscreen fps) along with unsightly > >>> shearing. > >>> > >>> I've thought about using the EventLoop class and overriding the idle() > >>> function, as that seems like it would let me evaluate code at much > >>> higher rates than framerate with vsync on (but less than while), and > >>> tick and flip when I need to (e.g. to get 30 fps), but a) you > >>> suggested that I not, being a n00b, and b) I don't know where to > >>> start, nor do I have any examples.. > >>> > >>> Please help. > >>> > >>> Thanks, > >>> Prantik > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "pyglet-users" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > [email protected]<pyglet-users%[email protected]> > . > >> For more options, visit this group at > http://groups.google.com/group/pyglet-users?hl=en. > >> > >> > > > > -- > You received this message because you are subscribed to the Google Groups > "pyglet-users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<pyglet-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/pyglet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
