Thanks jeff for the suggestion. I know how to use cProfile, most of the time is spent blitting, hence the journey into the blitting code.
On Tue, Mar 15, 2016 at 12:00 AM, Jeffrey Kleykamp < jeffrey.kleyk...@gmail.com> wrote: > 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 >
