Monthly Archives: August 2009

Fix for pygame/PyOpenGL/NeHe tutorial windows not disappearing when run from IDLE

30 August 2009

It’s a long weekend here in the UK and I thought I’d spend some time working through Paul Furber’s Python translations of the well-known NeHe OpenGL tutorial, which use the pygame and PyOpenGL libraries. (This is all with Python 2.6 on Windows XP.)

I noticed that when I ran the sample files from IDLE, the windows did not close — it didn’t matter whether I used the close box or hit escape; the program would seem to exit, but IDLE was in a messy state, and the OpenGL window would sit there not repainting.

Googling didn’t turn up anything that sounded relevant, but this archived mailing list message mentioned a pygame.quit() function that sounded relevant. I tried putting this at the end of each of the samples, and it seems to fix the problem.

[UPDATE: Of course, this fix is even better if put into a finally block, because then you’re covered when you introduce errors into the OpenGL code. Example below fixed appropriately.]

[Further UPDATE: Looks like this is the right thing to do — non-OpenGL Pygame FAQ here.]

An example:

def main():

    video_flags = OPENGL|DOUBLEBUF
    
    pygame.init()
    try:
        pygame.display.set_mode((640,480), video_flags)

        resize((640,480))
        init()

        frames = 0
        ticks = pygame.time.get_ticks()
        while 1:
            event = pygame.event.poll()
            if event.type == QUIT or (event.type == KEYDOWN and event.key == K_ESCAPE):
                break
        
            draw()
            pygame.display.flip()
            frames = frames+1

        print "fps:  %d" % ((frames*1000)/(pygame.time.get_ticks()-ticks))
    finally:
        pygame.quit()

Caveat: I’m a complete n00b with all of the technologies involved (except, debatably, Python), so this may be completely the wrong solution. But it works well enough for me to keep going with the tutorials for now.

Clicking the tabs from left to right

5 August 2009

It looks like visitors to the Resolver Systems website are predisposed to clicking through the tabs at the top of the page, from left to right. Does anyone else see this kind of thing?

The figures I’m using are from Google Analytics, which is based on JavaScript embedded in the page and run in the browser, so I don’t think it’s caused by bots/crawlers just clicking each of the tabs in turn because they appear in the page source code in that order — and in addition, if it were a result of automated systems, you’d expect a consistent bias, whereas it’s actually quite variable.

Here’s the full dataset. Each line below shows a Google Analytics overlay, which tells you for each selected tab what percentage of people clicked on each of the other tabs during July 2009:

Google Analytics overlay of tabs on home page
Google Analytics overlay of tabs on buy page
Google Analytics overlay of tabs on download page
Google Analytics overlay of tabs on products page
Google Analytics overlay of tabs on share page
Google Analytics overlay of screencasts on home page
Google Analytics overlay of tabs on help page
Google Analytics overlay of tabs on about page

It looks like we managed to break tracking of access to our “About us” page for that month, so I put the results for that tab aside and did a bit of simple statistical analysis (in Resolver One, naturally) on the remaining data. The results:

Analysis of the tab clickthrough behaviour

The “from” tab is top to bottom, the “to” tab is left to right — so, the chance of someone who is currently on the “Buy” tab clicking “Download” is 29%. The average chance of someone clicking on a given tab across all sources, and the standard deviation of those figures, are summarised at the bottom. Each cell is coloured based on how many standard deviations from the average it lies — if it’s more popular than it normally is, it appears red, if it’s less popular it’s green. The intensity of the red/green is based on how much more/less popular it is.

I think there’s a very clear pattern — the line of red starting at the “Home tab to Buy tab” cell, and going down and to the right to the “Screencasts tab to Get help tab” cell. That indicates that people are significantly more likely to click on a tab when it’s the one to the right of the one they’re currently looking at.

You can download the analysis spreadsheet from here, and if you don’t already have a copy of Resolver One to run it on (shame on you ;-), you can get an eval version here.

This is interesting — is it just our visitors, or have other people seen similar results?