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
