On Wed, Sep 10, 2008 at 12:09 PM, Elmo Trolla <[EMAIL PROTECTED]> wrote:
> I've created four test-programs, each one a slightly modified version > of the pyglet-1.1.1-docs.zip opengl.py example. WinMerge can be used > to quickly see the differences between these versions. > > http://etm.blastnet.ee/var/list/opengl_clock_schedule.py > http://etm.blastnet.ee/var/list/opengl_clock_schedule_interval.py > http://etm.blastnet.ee/var/list/opengl_fps_limit.py > http://etm.blastnet.ee/var/list/opengl_custom.py > > And here are the results I got: (copy-pasted from the py files) > > ---- > > opengl_clock_schedule.py > pyglet.clock.schedule(update) > > # > # after startup : 64 fps 0% cpu > # while moving mouse inside the window: 143..149 fps, 3% cpu > # after window resize or move : 3300..3500 fps, 60..70% cpu > (and stays this way) > # > # (core2duo e8200, nvidia 8800gt, xp sp2. 50% cpu means 100% of one > core) > # > # window.invalid = True has no effect on fps Thanks, this is fixed in r2259 (pyglet-1.1-maintenance) and r2260 (trunk). You should now see max FPS (3300-3500, for you) before resizing or moving the window; the problem was merely in event loop initialisation. > > ---- > > opengl_clock_schedule_interval.py > pyglet.clock.schedule_interval(update, ..) > > # > # param : fps cpu cpu while mousemove cpu after move or resize > # : > # 1/30. : 21 0% 3% 20..23% > # 1/60. : 32 0% 3% 32..39% > # 1/100.: 64 0% 3% 58..63% > # 1/200.: 64 0% 3% 62..75% > # > # no change if i move the window, or move mouse inside the window. > # These results are surprising (and don't match mine at all). You should see far higher FPS readings for the code you supplied for intervals 1/100 and 1/200; because the event loop degenerates to polling in this case (by design). For the 1/30 and 1/60 cases you should also see framerates far above the target interval. Note that to actually achieve the target framerate, you should set window.invalid to True in on_draw(), and to False in update(). This gives approximately the target framerate on my machine (slightly under, actually). There's definitely room for improvement if someone wants to write a better clock function, ideally using a better integration function, such as phased lock loop, to correct for jitter over longer time periods than the current implementation. I personally don't see this as a big necessity though -- developers should either be targetting low framerates (below 30) or the refresh rate (enable vsync); anything else just doesn't make sense. > > ---- > > opengl_fps_limit.py > pyglet.clock.set_fps_limit(..) > > # > # limit : fps cpu > # : > # 0 : 3400..3600 70..82% > # 1/30. : 29..60 14% > # 1/60. : 59..60 28% > # 1/100. : 99..102 44% > # 1/200. : 180..185 50% > # 1/400. : 126..130 50% > # 1/800. : 126..130 50% > # > # fps was NOT stable. even changing between 59..60 means jumpy > animations. > # > I'm not interested in attempting to make set_fps_limit work with the event loop; so long as it degenerates gracefully (as it seems to now) I'm happy -- the function is deprecated in favour of scheduling on the clock. > ---- > > opengl_custom.py > This has my own main-loop. Compare cpu usage.. And animations really > are as smooth without vsync as with (ok, some occasional tearing, but > absolutely no jumping). > > # > # fps_dt : fps cpu > # : > # 0. : 3400..3600 70..82% > # 1/60. : 60 0% > # 1/100. : 100 0% > # 1/200. : 200 0% > # 1/400. : 400 0..20% > # 1/800. : 800 50..76% > # > This event loop isn't very general: it only works for one window, and doesn't let events preempt the loop; making it ultimately more latent than the pyglet event loop, unless your application is non-interactive. It also doesn't run while windows are being moved or resized, or while menus are being tracked on OS X. > ---- > > Sadly I chose a bad example. Problems would've been much more visible > on a big rotating checkerboard. Well, until next time.. > > > Some of the jumpiness can be traced back to > > pyglet.clock.tick() > > returning too big values ~4 times per second (if the program runs at > 60fps), and too small values rest of the time. Using standard time > module > > dt = time.clock() - prev_clock > > is much more precise. Is this due to pyglet.clock using time.time() instead of time.clock()? Alex. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
