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

Re: [pygame] Faster blitting



Thanks for the benchmark, but your example is not using the SDL_LowerBlit. I did my own testing at home using SDL_LowerBlit and got similar results, meaning there is little difference between SDL_BlitSurface, and SDL_LowerBlit when all inputs are valid and optimal. As my use case has checked all the boxes for requiring optimized/lower-level blits (many small blits for small surfaces, all valid parameters without need to check each time), I felt compelled to test it. I will consider different approaches.

On Mon, Mar 14, 2016 at 5:19 PM, Peter Finlayson <frnknstn@xxxxxxxxxxx> wrote:
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