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
<[EMAIL PROTECTED]>
