[pygame] Re: Strange performance in blit

2014-04-26 Thread bw
Whoops. Forgive my haste and loss of focus right before sending that. 
There is a mistake.


Change line 89:
costs = []
to
costs_per_screen = []

Gumm

On 4/26/2014 18:01, bw wrote:

Howdy, folks,

I am getting some strange behavior in Surface.blit(). This is a mystery.

I blit a collection of images to to fill the screen. If I pan left or 
right even one pixel, blit consumes nearly 4x the CPU. It is only left 
or right: if I pan up or down performance is not impacted.


I've attached a program that attempts to demonstrate this. Hopefully 
you'll find it minimal and easy to comprehend. Please let me know:


- Am I doing something wrong, and how?
- Is this a legitimate issue, and how might I work around it?


Please read the program description for the steps to reproduce the issue:

"""strange.py - demonstrating strange performane in Surface.blit

This program fills a screen with sprites to produce a checkerboard 
background,

and demonstrates a problem.

Controls:

UP,DOWN,LEFT,RIGHT  pan the background
SPACE   center the background
ESCAPE  quit

Reproducing the problem:

The times indicated in these steps are on a Intel i3 running Windows 7 
64-bit.
Times will vary on other machines. The time cost measured is in blit 
ONLY.


1. Observe the cost per blit in the window's caption. On my machine it 
costs

   about 0.015 seconds per blit.
2. Pan LEFT one or more pixels. Note the cost goes up nearly 4x 
(0.056).
3. Press SPACE to center the background. Note the cost goes back down 
to the

   original value.
4. Pan RIGHT just one or more pixels. Note the costs goes up as in 
step 2.

5. Press SPACE to center the background.
6. Pan UP or DOWN: the cost is not impacted.
"""

Gumm




[pygame] Strange performance in blit

2014-04-26 Thread bw

Howdy, folks,

I am getting some strange behavior in Surface.blit(). This is a mystery.

I blit a collection of images to to fill the screen. If I pan left or 
right even one pixel, blit consumes nearly 4x the CPU. It is only left 
or right: if I pan up or down performance is not impacted.


I've attached a program that attempts to demonstrate this. Hopefully 
you'll find it minimal and easy to comprehend. Please let me know:


- Am I doing something wrong, and how?
- Is this a legitimate issue, and how might I work around it?


Please read the program description for the steps to reproduce the issue:

"""strange.py - demonstrating strange performane in Surface.blit

This program fills a screen with sprites to produce a checkerboard 
background,

and demonstrates a problem.

Controls:

UP,DOWN,LEFT,RIGHT  pan the background
SPACE   center the background
ESCAPE  quit

Reproducing the problem:

The times indicated in these steps are on a Intel i3 running Windows 7 
64-bit.

Times will vary on other machines. The time cost measured is in blit ONLY.

1. Observe the cost per blit in the window's caption. On my machine it costs
   about 0.015 seconds per blit.
2. Pan LEFT one or more pixels. Note the cost goes up nearly 4x (0.056).
3. Press SPACE to center the background. Note the cost goes back down to the
   original value.
4. Pan RIGHT just one or more pixels. Note the costs goes up as in step 2.
5. Press SPACE to center the background.
6. Pan UP or DOWN: the cost is not impacted.
"""

Gumm
"""strange.py - demonstrating strange performane in Surface.blit

This program fills a screen with sprites to produce a checkerboard background,
and demonstrates a problem.

Controls:

UP,DOWN,LEFT,RIGHT  pan the background
SPACE   center the background
ESCAPE  quit

Reproducing the problem:

The times indicated in these steps are on a Intel i3 running Windows 7 64-bit.
Times will vary on other machines. The time cost measured is in blit ONLY.

1. Observe the cost per blit in the window's caption. On my machine it costs
   about 0.015 seconds per blit.
2. Pan LEFT one or more pixels. Note the cost goes up nearly 4x (0.056).
3. Press SPACE to center the background. Note the cost goes back down to the
   original value.
4. Pan RIGHT just one or more pixels. Note the costs goes up as in step 2.
5. Press SPACE to center the background.
6. Pan UP or DOWN: the cost is not impacted.
"""

# Configurables.
resolution = (800, 600)
image_size = (16, 16)
max_fps = 100

import time
import pygame
from pygame.locals import *

pygame.init()
screen = pygame.display.set_mode(resolution)
screen_rect = screen.get_rect()
clock = pygame.time.Clock()

# graphics
colors = [
Color('red'),   # check 0
Color('orange'),# check 1
Color('black'), # screen erase
]
# images are shared among the sprites
images = {}
for i in (0, 1):
image = pygame.Surface(image_size)
image.fill(colors[i])
images[i] = image

# checkboard background
sprites = []
sign = {0:1, 1:-1}
for y in xrange(0, screen_rect.h, image_size[1]):
for x in xrange(0, screen_rect.w, image_size[0]):
sprite = pygame.sprite.Sprite()
sprite.rect = Rect((x, y), image_size)
# the next two lines produce the checkerboard pattern
yd = y // image_size[1] % 2
xd = yd + sign[yd] * (x // image_size[0] % 2)
sprite.image = images[xd]
sprites.append(sprite)

# camera
camera_rect = Rect(screen_rect)
camera_move = [0, 0]  # x, y

def do_events(events):
for e in events:
if e.type == KEYDOWN:
if e.key == K_ESCAPE: quit()
elif e.key == K_RIGHT: camera_move[0] += 1
elif e.key == K_LEFT: camera_move[0] -= 1
elif e.key == K_DOWN: camera_move[1] += 1
elif e.key == K_UP: camera_move[1] -= 1
elif e.key == K_SPACE: camera_rect.center = screen_rect.center
elif e.type == KEYUP:
if e.key == K_RIGHT: camera_move[0] -= 1
elif e.key == K_LEFT: camera_move[0] += 1
elif e.key == K_DOWN: camera_move[1] -= 1
elif e.key == K_UP: camera_move[1] += 1
elif e.type == QUIT: quit()

# main loop
blit = screen.blit
costs = []
avg_costs = []
while True:
screen.fill(colors[2])

# Do keys, and move camera.
clock.tick(max_fps)
do_events(pygame.event.get())
camera_rect.x += camera_move[0]
camera_rect.y += camera_move[1]

# Draw camera-translated sprites. Collect the timing of blit for each
# sprite on one screen.
del costs_per_screen[:]
cx, cy = camera_rect.topleft
for sprite in sprites:
r = sprite.rect.move(-cx, -cy)

## Curious: attempt to cull left or right columns doesn't matter.
## CPU cost still quadruples.
#if r.right > screen_rect.right or r.left < screen_rect.x:
#continue

## timing blit: pan

[pygame] New tool for building Windows installers

2014-04-26 Thread Thomas Kluyver
Hi all,

I'd like to invite people to test out Pynsist, my new open source tool to
build Windows installers for Python applications.

For instance, this is all I had to write to make an installer for the
'Aliens' example included in pygame:
https://github.com/takluyver/pynsist/blob/master/examples/pygame/installer.cfg

Using a pygame installer downloaded from Christoph Gohlke's site, I can
even build the installer on Linux and have it work on Windows.

Pynsist never tries to make an exe of your application, unlike freeze tools
such as cx_Freeze and Pyinstaller. Instead, it installs your code along
with a copy of Python, and creates start menu shortcuts to launch your
Python code directly. This produces bigger installers (but not huge -
Aliens is 27MB), but it is less brittle. Freeze tools often have problems
with packages that don't expect to be frozen, or break when a new version
of Python comes out; Pynsist avoids these issues.

Pynsist supports Python 3.3+ and Python 2.7.

To install and use Pynsist, see the documenation:
http://pynsist.readthedocs.org/en/latest/

Thanks,
Thomas