Does pyglet limit framerate?

[Thomas Hansen]

Hi,

I am a little unsure if I am getting less raw controll than I need or
whether I am making some other mistake. I am running a simple pyglet
application which just draws a blank frame and displays the fps
counter on the _draw event of the window. I cannot get this to run
any faster than 60fps.

I have tried passing 0 and None to the pyglet.clock.set_fps_limit
function. I have also tried overwriting the EventLoop's idle
function to call tick, dispatch the on_draw event , fip the window and
return 0. Neither of these apporaches let the application run faster
than 60fps.

I have run my simple script on both Mac OSX and Linux (pytho 2.5. I
am running this on a MacBookPro (2.4Ghz, 2Gb Ram and an Nvida 8600M GT
with 256gram). I know I can get *much* faster framerates drawing to a
openGL window on this machine.

I have run the test code below both with and without the -O option.
It always runs at 60fps.

Is there a way to get full control of the main loop to remove any
throtheling and just render as fast as I possibly can?

Thanks for any help,
Thomas


This is the code I am running code:

import pyglet

window = pyglet.window.Window()
fps_display = pyglet.clock.ClockDisplay()
pyglet.clock.set_fps_limit(0)


class rawEventLoop(pyglet.app.EventLoop):

def idle(self):
pyglet.clock.tick()
window.dispatch_event('on_draw')
window.flip()
window.invalid = True
return 0

@window.event
def on_draw():
window.clear()
fps_display.draw()

rawEventLoop().run()

[Richard Jones]

On Thu, Aug 7, 2008 at 9:19 AM, Thomas Hansen <thomas...@gmail.com> wrote:
> I am a little unsure if I am getting less raw controll than I need or
> whether I am making some other mistake. I am running a simple pyglet
> application which just draws a blank frame and displays the fps
> counter on the _draw event of the window. I cannot get this to run
> any faster than 60fps.

By default pyglet syncs to your monitor refresh rate. To disable set
the environment variable PYGLET_VSYNC=0 or pass vsync=0 to Window
creation.

Richard

[Thomas Hansen]

Ahh, that helped! thanx alot. 2200 fps seems more like it. :)

--
Thomas

On Aug 6, 6:48 pm, "Richard Jones" <r1chardj0...@gmail.com> wrote:

[3TATUK]

yeah but what is this issue with the FPS speeding up when moving my
mouse? even though I have clock.set_fps_limit(30)..

[3TATUK]

nevermind! i just had to manually invoke clock.tick() !

[even though i had clock.set_fps_limit(30)]

thanks!

ps. pyglet still needs working sound loops, alpha-aware blit_into(),
and monitor resolution changing !

thanks! :)

[3TATUK]

err nevermind cause now if I issue clock.tick() manually... the FPS
gets limited to lower than what I have clock.set_fps_limit() set to.
So I'm still having an issue. any idea?

[Richard Jones]

On Sun, 7 Sep 2008, 3TATUK wrote:
> ps. pyglet still needs working sound loops, alpha-aware blit_into(),
> and monitor resolution changing !

http://groups.google.com/group/pyglet-users/web/faq

[3TATUK]

Actually .. I've noticed pyglet (1.1.1) has serious issues as far as
framerate limiting/counting.

It's basically not possible to have it be consistent. If you use
clock.set_fps_limit() .. the FPS will go far above this when for
example moving the mouse around in the window. Also, A simple
clock.get_fps() usually returns something considerably different than
whet was specified with clock.set_fps_limit()

As far as Alex's official response to screen resolution changing ... I
_really_ think these capabilities are within pyglet's scope. Pyglet is
not a pure OpenGL wrapper (as PyOpenGL aims to be). Pyglet is A full
``cross-platform windowing and multimedia library for Python''.

Pyglet has windowing capabilities. Pyglet has screen capabilities. It
even has multi-monitor capabilities! Stating that monitor resolution
changing is out of the scope of Pyglet just seems a bit ridiculous to
me.

The ``issue'' with sound looping/seeking (not really an issue so much
as the code simply not existing in v1.1.1) is obviously known and
addressed because I see new code which seems to slowly be adding
functionality in newer svn revisions > v1.1.1.

I just think it's 'interesting' how the documentation 'acts as
if'/'pretends' that code actually exists and is functional. Maybe I'm
not comprehending the documentation revision process and it's actually
based on 'greater than current release' code, which may or may not be
available in SVN. Nevertheless, I think it's generally A good idea
for whatever's found at pyglet.org/doc to be up-to-date with the
latest -release- and let never documentation reside in the SVN.

And to this same topic it's interesting to note Alex's response at the
following page: http://groups.google.com/group/pyglet-users/browse_thread/thread/641516ebc0ec7736

Drew complains about on_eos() not working (as it shouldn't because the
code is skeleton in v1.1.1)... but Alex responds as if it should be
working, querying about 'platform / audio environment'. Maybe he
forgot that Drew is probably not working with the up-to-the-minute
codebase found on Alex's hard drive, or maybe he's polling for
information to take into account for continued development. Either
way it's interesting.

And finially .. the problem with texture-to-texture blitting not
preserving alpha [blit_into()]. I've actually contacted Alex directly
about this and what he had to say was:

<<< "In short, blit_into doesn't have this functionality, as it's not
exposed by the OpenGL API for image transfer."

"Also, would it not be smart to have a future version of blit_into()
have alpha functioning?"
>>> "No."

"Why not just have it exposed to OpenGL API for image transferring?"
>>> "I didn't write the OpenGL API, I only make use of it for pyglet ;-)"

I don't understand this logic. I understand his explanation as far is
blit() invoking GL rendering and blit_into() _not_ doing it.. But this
is just inconsistent API.

Again, Pyglet is ``a cross-platform windowing and multimedia library
for Python''. Python is a high-level language and I'm somewhat
presuming that Pyglet aim at bringing this access down to uses/
developers of Pyglet. Otherwise, why not just have the would-be users/
developers of Pyglet write their own OpenGL ctypes interface or use
PyOpenGL, instead?

texture.blit() invokes GL rendering which preserves alpha, but
texture.blit_into() does not. That's just seriously in-consistent.

If not have blit_into() invoke the GL renderer to preserve alpha, then
at least have it preserve alpha some other way. Personally I think
that would just be sane overall design.

If texture.blit() preserves alpha, texture.blit_into() should as well.

Anyway I just feel really strongly about these issues because I
believe Pyglet's has a lot of potential going for it.

I was a little pretentious about judging Pyglet since I'm used to
pygame which _does_ all of these things and I'm aiming at eventually
comprising something that can be considered a 'large' game project..
Which means that if such core issue's aren't address (ESPECIALLY
inconsistent FPS) then pyglet will simply not be a candidate for
further development. My game logic code is hardly advanced at all but
it's much easier to build this down the line when it's set on a strong
+stable core rendering framework.

Thank you Richard Jones. Thank you Alex Holkner. I hope no one is
upset by my sometimes-hash-seeming constructive criticism. ;)


Good health to you.

[Python Nutter]

I have observed similar issues with the framerate and clock and have
posted under issues no. 314 but I am not sure if pygame is any better.
It has the worst performance on my systems (Mac OS X) and also a very
large preinstallation hit of ~60MB for users on that platform. Before
the current release of pygame it was years without any released on my
platform. Current pygame release has it's own issues to deal with. I'm
still focusing on pyglet+rabbyt myself until I can get a chance to
play with pyglet 1.2 to test performance on.

Cheers,
PN