Re: [pygame] PixelArray question

[Lenard Lindstrom <len-l@xxxxxxxxx>]

Marcus von Appen wrote:
> On, Fri Aug 24, 2007, Lenard Lindstrom wrote:
>   
>   
> > Reducing the need for surfarray is good. I just wonder if PixelArray is the 
> > only place where slicing and mapping could be done. Slicing, for instance, 
> > could be a feature of the Surface fill and blit methods. They would take 
> > optional x and y step values. The blit method could also have additional 
> > blend options for color/alpha channel copying.
> >     
>
> Interesting point. The API change for it however would not be very
> intuitional, if we want to maintain backwards compatibility:
>
>              Surface.fill(color, rect=None, sliceargs=None)
>  
> Making the rect exchangeable with slicing arguments would break filling
> subareas limited by a rect. I'm not sure, what would be a good API, but
> stuff like 
>
>       Surface.fill(color, rect, [x:x1, ::2])
>       Surface.fill(color, rect, [x:x1:3])
>       Surface.fill(color, rect, [::2, 3:6])
>
> looks a bit odd to me. Blitting makes it even more complex with a source
> surface, rect arguments blending and slicing:
>
>          Surface.blit(source, dest, rect, flags, blendflags, [...])
>          ...
>   

I was not suggesting a new slice argument. In fill() and blit() the rect 
arguments already supply the boundary. What would be added is a step 
argument:

Surface.fill(color, rect, step)

where step is a tuple representing an x,y step pair. Example:

PixelArray(s)[::1, ::2]  = 0xff0000
# becomes
s.fill((255, 0, 0, 255), None, (1,2))

Notices the fill version is surface format independent.

As for a stepped blit, I cannot guess how to get a new Surface from a 
PixelArray to do this. Or will blit accept a PixelArray in place of a 
Surface. But an extended blit would be:

# For surface src of size (w,h)
# blit every second column of src to dest at location (0,0) as a (w, 
h//2) image
dest.blit(src, (0, 0), src.get_rect(), 0, 0, (1, 2))

An alternative to a separate step argument is to allow a six element 
tuple as the rect, with the last two elements being the x-step and 
y-step respectively. If the overhead of adding new features to blit and 
fill is a concern, the stepped blit and fill could be implemented as new 
methods or module functions.

--
Lenard Lindstrom
<len-l@xxxxxxxxx>