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
>>>
>>>
>>>
>>
>
>
