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

Re: [pygame] Pygame 2.0 software blits



Hi Keith,

It's still a little early to know how this will work out. I have to confirm that RPython's garbage collector properly handles multiple calls into the interpreter without resetting each time. But I don't think there is a problem.

Lenard Lindstrom

On 14-03-03 03:29 PM, Keith Nemitz wrote:

thanks for doing all this!
Keith Nemitz
Principal Developer
Mousechief Co.
www.mousechief.com

------------------------------------------------------------------------
*From:* Lenard Lindstrom <len-l@xxxxxxxxx>
*To:* Pygame Mail List <pygame-users@xxxxxxxx>
*Sent:* Monday, March 3, 2014 2:23 PM
*Subject:* [pygame] Pygame 2.0 software blits

Hi everyone,

I have taken a side excursion to test ways to replace Pygame's many hand coded blit loops with a more abstract loop generating mechanism (previously discussed in this tread <http://article.gmane.org/gmane.comp.python.pygame/21919/match=blit+jit>). One promising approach is a JIT powered blit interpreter<https://bitbucket.org/llindstrom/blitter> written in PyPy's RPython <http://doc.pypy.org/en/latest/getting-started-dev.html>. I have written a simple prototype, available at
https://bitbucket.org/llindstrom/blitter.

The blitter is implemented as an interpreted bytecode language that supports loops and byte copies. The prototype does integer array copies for different integer sizes and byte order. Array strides are supported. A code block is generated dynamically for each unique pair of source and target integer types encountered. Code blocks are cached. The actual blit is done by an interpreter executing the code block. What is useful is that the RPython compiler automatically creates the JIT for the interpreter loop. So the bytecode gets compiled to machine code and run directly. My simple prototype has copy speeds comparable to pygame.pixelcopy.array_to_surface(), a hand coded blitter written in C.

To keep the prototype blitter compatible with both CPython and RPython I wrote it as a standalone C shared library. The pure Python wrapper module uses CFFI. The C library is self contained; it has no Python dependencies whatsoever.

A Pygame level production blitter would extend the simple bytecode language to support basic arithmetic operations, different integer sizes, as well as higher level operations such as pixel encoding/decoding and alpha blitting. It would replace code in alphablit.c, pixelcopy.c, and freetype/ft_render_cb.c.

Just something to consider.

Lenard Lindstrom