[pyddr-devel] Performance, frame rate, and judging

[Dean Brettle]

On Fri, 2004-07-16 at 22:21, Stephen Thorne wrote:
> On Fri, Jul 16, 2004 at 03:18:51PM -0400, Dean Brettle wrote:
> <snip>
> > I tried changing the code so that the display updates and pad-polling
> > were done in separate threads, but Linux 
> (python)
> > wouldn't context switch regularly enough to fix the problem.  The only
> > other option I see is to sprinkle pad polling strategically around the
> > rest of the code.  Specifically, this would involve:
> > 
> > 1. Splitting the call to pygame.display.update() into multiple calls
> > (with non-overlapping rectangles), and adding polling between the calls.
> Thats a facinating idea. Have you tried it?

Not yet.  My profiling seems to indicate that only about half the time
is being spent in pygame.display.update(), so I seriously doubt I'd be
able to tell the difference if I only did that.  The bulk of the rest of
the time seems to be spent drawing and erasing various sprites (mostly
arrows). 

> 
> > 2. Adding polling inside some loops in player.py
> We'd have to do some serious investigation to see how well this would
> work.

Understood.

> 
> > 3. Perhaps, adding some polling in arrows.py.
> hmm. icky.

That's my feeling as well.  I'd only do it if I had to.

> 
> > Given that the HACKING file says "We should not sacrifice code clarity
> > for speed except in extreme cases", would a patch which makes the above
> > sorts of changes be considered for inclusion in a future release?
> Depends on how clear you make it I guess.

That's what I figured.  I just wanted to be sure it wouldn't be rejected
out-of-hand.  FWIW, the code I'm looking at "sprinkling" would just be
calls to a new function (tentatively named pad.queue_events()) that
polls and stores any events (and the current time) in an event queue. 
The actual handling of the events would still be done once per frame. 

I'll let you know when I have something worth reviewing.

--Dean