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 <le...@telus.net>
*To:* Pygame Mail List <pygame-users@seul.org>
*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
