Re: [SPAM: 8.000] [pygame] Pygame 2.0 software blits

[Lenard Lindstrom]

On 14-03-04 01:29 AM, Greg Ewing wrote:

Lenard Lindstrom wrote:
If the bytecode is exposed at the Python end then any expression can 
be encoded, a different one for each channel if desired. Conceivably, 
a Python expression, or function, could be compiled into a blit 
operation.


That would be even more awesome!


How does this look as an example:

def alpha_blend(source, target):
"""pygame.Surface.blit alpha blit blend

blit_blend(Color, Color) => Color

return a new target pixel value

"""
source_alpha = source.a
target.r = element_blend(source.r, target.r, source_alpha)
target.g = element_blend(source.g, target.g, source_alpha)
target.b = element_blend(source.b, target.b, source_alpha)
target.a = alpha_element_blend(source_alpha, target.a)
return target

def element_blend(source, target, alpha):
return (((source - target) * alpha + source) >> 8) + target

def alpha_element_blend(source, target):
return source + target - ((source * target) // 255)

"""
>>> from pygame import Color
>>> print alpha_blend(Color('red'), Color('green'))
(255, 0, 0, 255)
>>> print alpha_blend(Color(255, 0, 0, 128), Color('green'))
(128, 127, 0, 255)
>>> print alpha_blend(Color('red'), Color(0, 255, 0, 128))
(255, 0, 0, 255)
>>> print alpha_blend(Color(255, 0, 0, 128), Color(0, 255, 0, 128))
(128, 127, 0, 192)
>>>
"""

This shows how the blend function can be tested in Python. For the JIT, 
arguments are treated as pass-by-value, so changes to 'target' will not 
affect the target surface. Instead, the target pixel is set to the 
function's return value.


The Python function is traced to generate JIT code. For now, branching 
and recursion are unsupported. The JIT takes care of adding the row and 
column loops.


Inspired by PyPy RPython.

Lenard Lindstrom

Re: [SPAM: 8.000] [pygame] Pygame 2.0 software blits

[Greg Ewing]

Lenard Lindstrom wrote:
If the bytecode is exposed at the Python end then any expression can be 
encoded, a different one for each channel if desired. Conceivably, a 
Python expression, or function, could be compiled into a blit operation.


That would be even more awesome!

--
Greg

Re: [pygame] Pygame 2.0 software blits

[Lenard Lindstrom]

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 
*To:* Pygame Mail List 
*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

Re: [SPAM: 8.000] [pygame] Pygame 2.0 software blits

[Lenard Lindstrom]

On 14-03-03 02:48 PM, Greg Ewing wrote:

Lenard Lindstrom wrote:
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.


This sounds very interesting, especially if it allows a
wider and more useful set of operations to be supported,
such as specifying separate combining functions for rgb
and alpha channels.

If the bytecode is exposed at the Python end then any expression can be 
encoded, a different one for each channel if desired. Conceivably, a 
Python expression, or function, could be compiled into a blit operation.

Re: [SPAM: 8.000] [pygame] Pygame 2.0 software blits

[Greg Ewing]

Lenard Lindstrom wrote:
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.


This sounds very interesting, especially if it allows a
wider and more useful set of operations to be supported,
such as specifying separate combining functions for rgb
and alpha channels.

--
Greg

Re: [pygame] Pygame 2.0 software blits

[Keith Nemitz]

thanks for doing all this!


 
Keith Nemitz
Principal Developer
Mousechief Co.
www.mousechief.com



 From: Lenard Lindstrom 
To: Pygame Mail List  
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

[pygame] Pygame 2.0 software blits

[Lenard Lindstrom]

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 
). 
One promising approach is a JIT powered blit 
interpreter written in PyPy's 
RPython . 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