[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[pygame] What to do with PixelArray?
Hi,
The last few days I've been adding an array struct interface to
PixelArray. This lets a PixelArray object be converted to another type
that recognizes the interface, (e.g. a NumPy array, though why one would
do that is beyond me). However, in doing so I uncovered a bug slicing (A
unit test exposing the bug was committed as rev. 3109). The bug was
fixed in rev. 3126.
In fixing the bug and adding an array interface I found it easier to
rework the PixelArray internals to use shape and strides rather than
start, stop, and step. While doing so I discovered several unique
PixelArray behaviors. <1> There was no way to get a (1, h) or (w, 1)
PixelArray. The array would be one dimensional instead. <2> A sequence
(e.g. list) of integers can be assigned to a PixelArray as a sequence of
colors. However, a length 3 sequence is treated as a single (r, g, b)
color. What about the (unlikely) case of assigning a sequence to a (3,
h) PixelArray? <3> if a sequence is not length w, but rather length h,
it is copied to each column rather than row. What is to be done with a
square surface?
Behavior <1> was changed in rev. 3126. A one dimensional PixelArray is
only created for an integer index (e.g. pixel_array[2, :]). Behavior <2>
might be handled by regarding a pygame.Color or tuple object as a single
(r, g, b[, a]) color, while any other sequence is handled as a sequence
of colors. I don't know what to do with behavior <3>. It has a specific
test in the PixelArray unit tests.
So I see two options. First, I can revert PixelArray back to before I
reworked it, since some of the modifications are not backward
compatible. Then I would add my reworked version as a new array type.
Second, I can go ahead and make the changes I see as necessary, even
when they break backward compatibility. Specifically for behavior <3>, I
would remove it. Instead I would provide a transpose method that flips
the PixelArray rows and columns. No special treatment would be made for
(w, 1) and (1, h) arrays since special treatment could hide mismatched
surface bugs.
I am open to suggestions.
Lenard Lindstrom