[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Faster blitting



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 <greg.ewing@xxxxxxxxxxxxxxxx> 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