I have a code scrap for a potential "Surface.blit_list" method. The method would accept a list of (surface, rect) tuples. I've gotten about 15% increase in execution time compared to a python loop which does that same. If anybody is interested, I can do patch files, pull requests, whatever. I'm sure that the code leaks or is not optimal, but it is working, strictly as a test.
https://gist.github.com/bitcraft/1785face7c5684916cde On Mon, Mar 14, 2016 at 8:44 PM, Leif Theden <leif.the...@gmail.com> wrote: > Lol, daniel, I'm doing that right now. > > On Mon, Mar 14, 2016 at 8:15 PM, Daniel Foerster <pydsig...@gmail.com> > wrote: > >> Perhaps a function to blit multiple surfaces at once would be more >> helpful? >> >> >> On 03/14/2016 07:01 PM, Leif Theden wrote: >> >> 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 <frnkn...@iafrica.com> >> 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 < >>>> <frnkn...@iafrica.com>frnkn...@iafrica.com >>>> <mailto:frnkn...@iafrica.com>> 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 >>>> >>>> >>>> >>> >> >> >
