Hi, This point was made but not exactly in this way. The pixel format, bounds checks, and clipping checks are on the order of 9 operations, if pixel_format_1 != pixel_format_2: do something if bound_left_1 < bound_left_2: do something <add right, top and bottom checks> if image_left and clip overlap: do something
compared to about 5 * 100 operations to add two 10x10 sprites in an operation like (I made this formula up but you get the idea), new_pixel_xy = old_pixel_1_xy * (255 - old_pixel_2_alpha_xy) + old_pixel_2_xy * old_pixel_2_alpha_xy So I doubt removing the checks would make much difference. Not to discourage further thought down this road, but any slowness is probably due to some other optimization problems. The OP might want to try, python -m cProfile -s cumulative <yourscript.py> Also remember to do surface.convert() or surface.convert_alpha() on each surface. Jeff On Mon, Mar 14, 2016 at 10:06 PM, Leif Theden <leif.the...@gmail.com> wrote: > 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 >>>>> >>>>> >>>>> >>>> >>> >>> >> > -- Jeffrey Kleykamp
