[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Faster blitting

Well, if it gives you any satisfaction... I am not a pygame-team developer, but Ubuntu makes building this stuff easy-ish.
I wrote a quick test script, using cProfile for timing information. I stripped almost everything out of the blit call, both in PySurface_Blit() and surf_blit() which calls it. 

*Results with blit()*

372532 function calls (370644 primitive calls) in 13.809 seconds
ncalls  tottime  percall  cumtime  percall filename:lineno(function)
288000 8.232 0.000 8.232 0.000 {method 'blit' of 'pygame.Surface' objects} 
   600    5.080    0.008    5.080    0.008 {pygame.display.flip}


*Results with unsafe_blit()*

372532 function calls (370644 primitive calls) in 13.899 seconds
ncalls  tottime  percall  cumtime  percall filename:lineno(function)
288000 8.231 0.000 8.231 0.000 {method 'blit' of 'pygame.Surface' objects} 
   600    5.125    0.009    5.125    0.009 {pygame.display.flip}
Sorry, guys. There really wasn't much there to strip out. Just a couple of if statements. 

Here is are the C functions I used:
https://bitbucket.org/snippets/frnknstn/bKqAz

Here is the test Python code I used:
https://bitbucket.org/snippets/frnknstn/dKqAr

Regards,
Peter Finlayson



On 2016/03/14 08:55 PM, Leif Theden wrote:

Thanks for taking the time Peter to do this benchmark, but I don't believe that
this is testing the overhead that exists in the pygame C code.  To clarify, your
benchmark is slightly contrived in that it is doubling the python workload, when
I am interested in seeing the results of getting lower to SDL blitting.  I get
your message, I am absolutely clear that python is generally the bottleneck.  If
you can find a way to isolate and test the following parts of the C extension
library, I would be happy to see the results.

https://bitbucket.org/pygame/pygame/src/d61ea8eabd56025fcb4ceb24d63f9a6a30fbe8d4/src/surface.c?at=default&fileviewer=file-view-default#surface.c-2988:3114



On Mon, Mar 14, 2016 at 12:06 PM, Peter Finlayson <frnknstn@xxxxxxxxxxx
<mailto:frnknstn@xxxxxxxxxxx>> wrote:

    On 2016/03/14 04:35 PM, herve wrote:

        before being a skilled pygame developer, there is a newby developer and
        _maybe_
        giving him good performance for simple things will let him stay and
        growing to
        skilled developer.


    A newbie developer seeing a "faster" unchecked function, trying to use it,
    and then getting discouraged when it inevitably fails... That is exactly why
    unsafe_blit() is a bad fit for Pygame.

    If you want a quick benchmark to show you are barking up the wrong tree, you
    can do one at home, with no C experience needed! Take some game code you
    wrote, and run it three ways:

    1. Once unaltered
    2. Once where you run the sprite update code twice (logic, movement and physics)
    3. Once where you draw every sprite twice

    Record the FPS every time and see if that shows you where the real
    bottleneck lies. Here are the results I got from one of my projects:

    1. Base:        125 FPS
    2. Double logic: 75 FPS
    3. Double draw: 115 FPS

    I had to take the game all the way up to 6x draw calls per frame (4000+
    blits!) before I got it down to the 75 FPS mark.

    The point here is that if I was writing a game to have even double the
    sprites I do now, the game logic overhead would be the problem. Even if the
    unsafe_blit() magically doubled the speed of my draw routines, it would have
    little effect on my overall frame rate.

    Regards,
    Peter Finlayson