Re: [pygame] Faster blitting

[Leif Theden]

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
> 
> 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 
>
> 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 
> 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 
>> wrote:
>>
>>> Lol, daniel, I'm doing that right now.
>>>
>>> On Mon, Mar 14, 2016 at 8:15 PM, Daniel Foerster 
>>> 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 
 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)
> 2880008.2320.0008.2320.000 {method 'blit' of
> 'pygame.Surface' objects}
>6005.0800.0085.0800.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)
> 2880008.2310.0008.2310.000 {method 'blit' of
> 'pygame.Surface' objects}
>6005.1250.0095.1250.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=file-view-default#surface.c-2988:3114
>>
>>
>>
>> On Mon, 

Re: [pygame] Faster blitting

[Jeffrey Kleykamp]

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

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 

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  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 
> wrote:
>
>> Lol, daniel, I'm doing that right now.
>>
>> On Mon, Mar 14, 2016 at 8:15 PM, Daniel Foerster 
>> 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 
>>> 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)
 2880008.2320.0008.2320.000 {method 'blit' of
 'pygame.Surface' objects}
6005.0800.0085.0800.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)
 2880008.2310.0008.2310.000 {method 'blit' of
 'pygame.Surface' objects}
6005.1250.0095.1250.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=file-view-default#surface.c-2988:3114
>
>
>
> On Mon, Mar 14, 2016 at 12:06 PM, Peter Finlayson <
> 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 

Re: [pygame] Faster blitting

[Leif Theden]

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

> Lol, daniel, I'm doing that right now.
>
> On Mon, Mar 14, 2016 at 8:15 PM, Daniel Foerster 
> 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 
>> 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)
>>> 2880008.2320.0008.2320.000 {method 'blit' of
>>> 'pygame.Surface' objects}
>>>6005.0800.0085.0800.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)
>>> 2880008.2310.0008.2310.000 {method 'blit' of
>>> 'pygame.Surface' objects}
>>>6005.1250.0095.1250.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=file-view-default#surface.c-2988:3114



 On Mon, Mar 14, 2016 at 12:06 PM, Peter Finlayson <
 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 

Re: [pygame] Faster blitting

[Leif Theden]

Lol, daniel, I'm doing that right now.

On Mon, Mar 14, 2016 at 8:15 PM, Daniel Foerster 
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 
> 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)
>> 2880008.2320.0008.2320.000 {method 'blit' of
>> 'pygame.Surface' objects}
>>6005.0800.0085.0800.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)
>> 2880008.2310.0008.2310.000 {method 'blit' of
>> 'pygame.Surface' objects}
>>6005.1250.0095.1250.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=file-view-default#surface.c-2988:3114
>>>
>>>
>>>
>>> On Mon, Mar 14, 2016 at 12:06 PM, Peter Finlayson <
>>> 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
>>>
>>>
>>>
>>
>
>

Re: [pygame] Faster blitting

[Daniel Foerster]

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 > 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)
2880008.2320.0008.2320.000 {method 'blit' of
'pygame.Surface' objects}
   6005.0800.0085.0800.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)
2880008.2310.0008.2310.000 {method 'blit' of
'pygame.Surface' objects}
   6005.1250.0095.1250.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=file-view-default#surface.c-2988:3114



On Mon, Mar 14, 2016 at 12:06 PM, Peter Finlayson

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

Re: [pygame] Faster blitting

[Leif Theden]

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 
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)
> 2880008.2320.0008.2320.000 {method 'blit' of
> 'pygame.Surface' objects}
>6005.0800.0085.0800.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)
> 2880008.2310.0008.2310.000 {method 'blit' of
> 'pygame.Surface' objects}
>6005.1250.0095.1250.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=file-view-default#surface.c-2988:3114
>>
>>
>>
>> On Mon, Mar 14, 2016 at 12:06 PM, Peter Finlayson > > 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
>>
>>
>>
>

Re: [pygame] Faster blitting

[Greg Ewing]

Ian Mallett wrote:
​I think the point is that in the case where you have a lot of small 
blits, the proportional overhead of the checks is more significant.


If you have a lot of small blits, I'd expect the general
overhead of Python code overhead to swamp everything else.

--
Greg

Re: [pygame] Faster blitting

[Peter Finlayson]

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)
2880008.2320.0008.2320.000 {method 'blit' of 'pygame.Surface' 
objects}

   6005.0800.0085.0800.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)
2880008.2310.0008.2310.000 {method 'blit' of 'pygame.Surface' 
objects}

   6005.1250.0095.1250.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=file-view-default#surface.c-2988:3114



On Mon, Mar 14, 2016 at 12:06 PM, Peter Finlayson > 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

Re: [pygame] Faster blitting

[Leif Theden]

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=file-view-default#surface.c-2988:3114



On Mon, Mar 14, 2016 at 12:06 PM, Peter Finlayson 
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
>

Re: [pygame] Faster blitting

[Peter Finlayson]

Hi,

Thanks, Leif, I will have a look when I can. It hopefully won't be too 
unfamiliar to me, I already use your PyTMX everywhere :)


Regards,
Peter Finlayson


On 2016/03/14 06:24 PM, Leif Theden wrote:

Peter, the project that I am working on is here:
https://github.com/bitcraft/pyscroll/blob/master/pyscroll/orthographic.py.  It
is an "adaptive tile refresh" tile map renderer.

Re: [pygame] Faster blitting

[Peter Finlayson]

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

Re: [pygame] Faster blitting

[Leif Theden]

Thanks everyone, all good points about converting surfaces, pre-rendering
maps, slowness of python interpreter, etc.  The core issue is exposing some
of SDL's more lower level, less forgiving API, for platforms/projects that
might [theoretically] benefit from it.  For the record, all of my surfaces
are created with pygame.SRCALPHA or loaded and transformed with
Surface.convert_alpha().  Please, no suggestions about not using the alpha
channel, as it is important.  I am merely stating that I have already taken
care of matching pixel formats.

jcupitt, warnings are only useful for teaching, not for performance (still,
might be a nice addition to pygame...fire warnings at the developer until
they fix it :).
Peter, the project that I am working on is here:
https://github.com/bitcraft/pyscroll/blob/master/pyscroll/orthographic.py.
It is an "adaptive tile refresh" tile map renderer.
Matti, your RenderSurface idea is similar to what I am doing...  A big
surface that can be rendered iteratively with tiles.d

For what it is worth, I have begun to crudely patch in support for a lower
level access to SDL 1.2's blitting functions, strictly as a proof of
concept.  No guarantees on correctness, as I have not used C since high
school, and never studied the cpython API.  I'll keep the list posted.

On Mon, Mar 14, 2016 at 9:52 AM, bw  wrote:

> The request for SDL_LowerBlit makes sense to me if it opens an alternative
> avenue to optimize a game's renderer that works better on an under-powered
> platform. Some checks done in advance do not have to be recalculated
> repeatedly.
>
> That pygame, by its compiled nature, limits extensibility has been a
> tradeoff that sometimes I have not appreciated, though I understand and
> agree with why it had to be this way. Not a criticism, but a critique that
> I think is apt for this discussion.
>
> Gumm
>
>
> On 3/13/2016 2:06 PM, Leif Theden wrote:
>
> Heh, hostility is fun, right?  I am not a C programmer, please pay
> attention.  I have used colorkey, but that is not a straightforward way to
> increase speed.  Since it involves a check on each pixel, some images may
> not benefit (and in fact will lower performance) if there isn't much
> transparency.  Wheras a 'blit' on matched pixel format surfaces can be a
> simple memory copy operation, depending on the platform.
>
> To illustrate a use case for an "unsafe blit":  In tile map drawing, you
> will be doing potentially hundreds of blit operations.  Since tile
> placement is very straightforward, you can be sure there will be no
> out-of-bounds blitting.  You can enforce pixel formats when the surfaces
> are loaded.  So, format checks are only needed when surfaces are loaded,
> not every time there is a blit operation.  (Also, this is just one
> potential scenario, please don't elaborate on different way to render a
> tile-based map, just stick to the topic: "unsafe/fast blit")
>
> As is, the 'blit' operation removes several chances for error, especially
> for people who don't care to convert surfaces or set clipping regions, but
> it does so at a performance cost.
>
> It could be as simple as making the following function available to
> pygame, perhaps in some inconspicuous place, not a part of the surface
> class...in order to discourage abuse:
> 
> https://wiki.libsdl.org/SDL_LowerBlit
>
> On Sun, Mar 13, 2016 at 3:10 PM, 
> mspaintmaes...@gmail.com  wrote:
>
>> I don't think this is a trolling scheme. Since OP said this would
>> "obviously cause graphical errors" if the input was bad, I don't think they
>> are going to be surprised and then file a bug. Also, non-C programmers are
>> programmers, too :P
>>
>> Since a hypothetical "fast_blit" (or possibly "unsafe_blit") requires the
>> user to make sure all the formats are the same, bounds are checked, etc
>> ANYWAY, the overhead of normal blit's rule-enforcement would basically be a
>> no-op, ergo normal blit is the same as fast_blit if used with the proper
>> inputs. Are you familiar with color_key? If you're using blits with
>> per-pixel alpha and you don't need translucency, switching to color-key
>> usually gives a noticeable performance boost such that any rendering code
>> slowness is dwarfed by non-rendering code.
>>
>> On Sun, Mar 13, 2016 at 12:18 PM, Martti Kühne < 
>> mysat...@gmail.com> wrote:
>>
>>> So you're not a programmer but you want a fast method that potentially
>>> delivers surprising results because you don't want to care about the
>>> pixel format?
>>>
>>> I'm starting to suspect an elaborate trolling scheme here. Are you
>>> planning to file a bug about the surprising results then, already?
>>>
>>> cheers!
>>> mar77i
>>>
>>
>>
>
>

Re: [pygame] Faster blitting

[bw]

The request for SDL_LowerBlit makes sense to me if it opens an 
alternative avenue to optimize a game's renderer that works better on an 
under-powered platform. Some checks done in advance do not have to be 
recalculated repeatedly.


That pygame, by its compiled nature, limits extensibility has been a 
tradeoff that sometimes I have not appreciated, though I understand and 
agree with why it had to be this way. Not a criticism, but a critique 
that I think is apt for this discussion.


Gumm

On 3/13/2016 2:06 PM, Leif Theden wrote:
Heh, hostility is fun, right?  I am not a C programmer, please pay 
attention.  I have used colorkey, but that is not a straightforward 
way to increase speed.  Since it involves a check on each pixel, some 
images may not benefit (and in fact will lower performance) if there 
isn't much transparency.  Wheras a 'blit' on matched pixel format 
surfaces can be a simple memory copy operation, depending on the platform.


To illustrate a use case for an "unsafe blit":  In tile map drawing, 
you will be doing potentially hundreds of blit operations.  Since tile 
placement is very straightforward, you can be sure there will be no 
out-of-bounds blitting. You can enforce pixel formats when the 
surfaces are loaded. So, format checks are only needed when surfaces 
are loaded, not every time there is a blit operation.  (Also, this is 
just one potential scenario, please don't elaborate on different way 
to render a tile-based map, just stick to the topic: "unsafe/fast blit")


As is, the 'blit' operation removes several chances for error, 
especially for people who don't care to convert surfaces or set 
clipping regions, but it does so at a performance cost.


It could be as simple as making the following function available to 
pygame, perhaps in some inconspicuous place, not a part of the surface 
class...in order to discourage abuse: 
https://wiki.libsdl.org/SDL_LowerBlit


On Sun, Mar 13, 2016 at 3:10 PM, mspaintmaes...@gmail.com 
 > wrote:


I don't think this is a trolling scheme. Since OP said this would
"obviously cause graphical errors" if the input was bad, I don't
think they are going to be surprised and then file a bug. Also,
non-C programmers are programmers, too :P

Since a hypothetical "fast_blit" (or possibly "unsafe_blit")
requires the user to make sure all the formats are the same,
bounds are checked, etc ANYWAY, the overhead of normal blit's
rule-enforcement would basically be a no-op, ergo normal blit is
the same as fast_blit if used with the proper inputs. Are you
familiar with color_key? If you're using blits with per-pixel
alpha and you don't need translucency, switching to color-key
usually gives a noticeable performance boost such that any
rendering code slowness is dwarfed by non-rendering code.

On Sun, Mar 13, 2016 at 12:18 PM, Martti Kühne > wrote:

So you're not a programmer but you want a fast method that
potentially
delivers surprising results because you don't want to care
about the
pixel format?

I'm starting to suspect an elaborate trolling scheme here. Are you
planning to file a bug about the surprising results then, already?

cheers!
mar77i

Re: [pygame] Faster blitting

[herve]

On 14/03/2016 12:03, Martti Kühne wrote:

Sorry for ridiculing the original post. I was tired and OP made it
sound like homework for someone else, which happens far too often in
many projects.

cheers!
mar77i

I am sorry, too, for what i'm doing.

In many projects programmers take the habit of doing things the same 
way, always the same way and always responding to people asking for 
improvement : make a patch or your idea is stupid and i show you how you 
can live without it. That's normal way of doing. More, some times 
someone finding a bug and a solution to fix it can be responded : you 
solution is stupid, i can"t reproduce your bug, you should do this or 
that. And then... the guy go away and sometime choose another software.


You cannot want people ton invest time in your software when  you slam 
the door when they point an idea (good or not). For the one who have the 
code, the skiil, the compilation chain, it could take 5-10 minutes top 
make a benchmark bypassing some test in the code. It would take too much 
effort for the newby so he can't test. And the manner you respond him 
will forge his vision of who you are and how you treat people. And will 
never ever contribute, and maybe will choose another way, another soft, 
another framework.


If you want to continue alone or with the same 'crew', that's fine, but 
remember what happened to sodipodi.


It's maybe a stupid idea, or maybe not, without benchmark we don't know. 
Of course one can work on his code to gain performance elsewhere, but 
the underlying framework have a performance pattern that can _maybe_ be 
improved. Showing him, helping him entering smoothly in the sofware is, 
in my opinion, a much better bet for the future. 99 will just say thanks 
and continue their life, 1 will stay helping for things or other 
(writing code that test things for exemple : if he write some animation 
that test different way of blitting : everybody will benefit from it). 
_I_ do think that taking time for 100 and getting 1 that stay worth it 
nowadays. Even if it's 'homework' for ... everybody. (to know if tests a 
cut in performance or not).


I can understand that a skill user of pygame won't benefit much of that 
performance increase, because he took the habit of working differently 
(maybe more complex code, more complex algorithm, more complex way of 
thinking...) but 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.


just my opinion.
hervé

Re: [pygame] Faster blitting

[Martti Kühne]

A significant performance boost is achievable by caching intermediate
render results in your render function's dependencies. For an RTS-type
map, you'd then go render the map once when loading, instead of every
frame and save the amount of work to be done. You might even want to
passively detect dependencies and evaluate what parts of your render
pipe need to be updated with reasonable performance.
Which brings me to another suggestion: Do we want this kind of
infrastructure in a pygame.RenderSurface? - that would have a rect
position, maybe a target surface and a subsurface state stored and
pygame would figure out internally what it takes for an update based
on what was changed.

Sorry for ridiculing the original post. I was tired and OP made it
sound like homework for someone else, which happens far too often in
many projects.

cheers!
mar77i

Re: [pygame] Faster blitting

[Peter Finlayson]

Hi Leif,

The case where having an unsafe_blit() function would make a significant improvement on performance is (as you 
suggested) where you have a very large number of small blits. However, there are some important things to consider:


1. the overhead in the Python code that could produce that number of blits eclipses the cost of doing the checks. In the 
time it takes to create one or two Rects, Pygame would be able to do the checks and clipping for a hundred sprites.


2. In any real-world use case (even the best example you came up with), you need at least some of the checks the code 
performs. To implement that *subset* of checks in Python would be a dozen times slower than having ALL the existing checks.


3. The checks are fast enough on any modern platform, even the Raspberry Pi. I mean, have you tried one of those 
Raspberry Pi 3s? They are nippy!


In short, removing the checks would result in marginal gains. If you have some code that is experiencing unacceptable 
performance, we would be happy to look it over and suggest algorithmic changes. Those changes would result in a much 
bigger improvement than could be achieved by trying to shoehorn in unsafe blits.


Regards,
Peter Finlayson


On 14/03/2016 02:43, Leif Theden wrote:
How could I?  I appreciate the skepticism, but if fast_blit is not implemented, how could I test the overhead? And, it 
is not just format checking, it is also clipping and bounds checking.


On Sun, Mar 13, 2016 at 6:22 PM, Greg Ewing > wrote:

Leif Theden wrote:

The fast_blit method would with the barest minimum of checking before 
calling the sdl blitting functions.


Have you performed any measurements to find out whether
the checking overhead is significant in the cases where
the formats do match? Without evidence, I'm skeptical
about that.

-- 
Greg

Re: [pygame] Faster blitting

[Ian Mallett]

On Mon, Mar 14, 2016 at 1:41 AM, Javier Paz  wrote:

> I also agree with Greg. My experience tells me that, in order to have a
> significant overhead, you must have a loop.
>
​I think the point is that in the case where you have a lot of small blits,
the proportional overhead of the checks is more significant.

My (C++) codebase supported something similar, and I noticed (in my code)
that the checks were pretty cheap, unless you had a lot of blits to do.
Then, they were still cheap, but pointless. My solution? Only allow blits
between surfaces of like type (and it won't compile if you try). This works
out great--on the CPU, you don't really ever want to blit anything other
than RGBA8 anyway (even if you don't have an alpha, you should use RGBA,
because of SIMD and alignment). This forces you to make a copy if you
*really* want to blit--but that's sortof what the blitter would already
have to do, in a slower (less instr. locality), less elegant, one-off way.

So one *could* drop support for a lot of surface types (I know there was
talk about doing this anyway). But, at some point you have to remember that
your game is written in Python. If you want to scrape out the last 1% of
your performance, why are you using a scripting language in the first
place? And sure, the underlying library oughtn't to be deliberately slow,
but I think I value flexibility over minor performance gains. Of course,
maybe we *can* get rid of some surface types that no one actually uses, and
get a bit of both . . .

Ian​

Re: [pygame] Faster blitting

[Javier Paz]

I also agree with Greg. My experience tells me that, in order to have a
significant overhead, you must have a loop.

Overhead that doesn't modify the O performance value are caused in most
cases by loops whose number of iterations are independent of the input
size. Checks alone are very unlikely to cause a significant overhead. In C
and x86 architecture a simple if compiles only to 2 or 3 bytecode
instructions.
On 13 March 2016 at 23:22, Greg Ewing  wrote:
> Leif Theden wrote:
>> The fast_blit method would with the barest minimum of checking before
>> calling the sdl blitting functions.
>
> Have you performed any measurements to find out whether
> the checking overhead is significant in the cases where
> the formats do match? Without evidence, I'm skeptical
> about that.

I agree with Greg, the checks themselves are very unlikely to take a
significant amount of time.

I think Leif is right though that the forgiving nature of the blit
functions makes it easy to have horrible performance problems in your
code and to be completely unaware of them. How about adding a thing to
print warnings about issues like this?

You'd something like this to your game:

  pygame.set_performance_warnings(True)

And then in the blit code, there would be extra stuff like this:

  if (src->format != dst->format) {
if (performance_warnings)
  printf ("** performance warning: bit: src and dst formats do not
match\n");
format_convert (src, dst->format);
  }

ie. it would warn you that extra conversions were being done behind your
back.

Now to speed up your game, you just need to turn on the warnings and
try to stop your inner loops printing things. No doubt other parts of
pygame do similar things to this.

I'm a C programmer, I'd be happy to make a small patch to add
something like this if there's interest.

John

Re: [pygame] Faster blitting

[jcupitt]

On 13 March 2016 at 23:22, Greg Ewing  wrote:
> Leif Theden wrote:
>> The fast_blit method would with the barest minimum of checking before
>> calling the sdl blitting functions.
>
> Have you performed any measurements to find out whether
> the checking overhead is significant in the cases where
> the formats do match? Without evidence, I'm skeptical
> about that.

I agree with Greg, the checks themselves are very unlikely to take a
significant amount of time.

I think Leif is right though that the forgiving nature of the blit
functions makes it easy to have horrible performance problems in your
code and to be completely unaware of them. How about adding a thing to
print warnings about issues like this?

You'd something like this to your game:

  pygame.set_performance_warnings(True)

And then in the blit code, there would be extra stuff like this:

  if (src->format != dst->format) {
if (performance_warnings)
  printf ("** performance warning: bit: src and dst formats do not
match\n");
format_convert (src, dst->format);
  }

ie. it would warn you that extra conversions were being done behind your back.

Now to speed up your game, you just need to turn on the warnings and
try to stop your inner loops printing things. No doubt other parts of
pygame do similar things to this.

I'm a C programmer, I'd be happy to make a small patch to add
something like this if there's interest.

John