[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] PixelArray question

Brian Fisher wrote:

On 8/22/07, Marcus von Appen <mva@xxxxxxxxxxxx> wrote:

Sure. And anything else, what might be added to the PixelArray later on,
as well. As a result we would have a glorious
can-do-anything-implements-all-python-interfaces class called Surface :-).


[snip]


From my perspective, I think the core issue is whether PixelArray
manages any additional data or state that wouldn't make sense to be in
Surface, or would be easier to use if it wouldn't be in the surface.
If all it's data and state is simply copied from Surface, then all it
serves as an object is boiler plate code for the user to type that
duplicates data from the surface object you built it from.

And in fact, if you look at the constructor for PixelArray, it seems
at first to be exactly that kind of class (one with no additonal state
or data of it's own):
---
    return (PyObject *) _pxarray_new_internal
        (type, surfobj, 0, (Uint32) surface->w * surface->h,
         (Uint32) surface->w, (Uint32) surface->h, 1, 1, (Uint32) surface->w,
         NULL);
---
every argument is copied exclusively from the one surface.

However looking deeper it seems like there are 2 feature where the
pixelarray starts mainting some real data of it's own

first seems to be - slicing. There it constructs a new PixelArray with
parameters that are modified to access a subset of the surface's
pixels:
---
    return (PyObject *) _pxarray_new_internal
        (&PyPixelArray_Type, array->surface, start, end, xlen, ylen,
         xstep, ystep, padding, (PyObject *) array);
---
...however keeping PixelArray as a seperate object but hiding it as an
"interface" would still serve the same goals

the second seems to be that it manages locking the surface over it's
lifetime - so making it an external interface is useful there.


So I think the answer to why it couldn't be part of surface is slicig
& automagic managing or surface locking...
There was also the question of the buffer interface. A Surface is an SDL surface, so it could be argued that a buffer interface on a Surface should return the SDL_Surface structure. PixelArray represents the raw pixels, so a buffer interface on it returns just the pixel data.
As for slicing, that is just a generalized form of Surface.subsurface (with the parent locked for consistency with surfarray). But I appreciate that time constraints prohibit adding something like strides to a subsurface. Thus the stripped down PixelArray. 

--
Lenard Lindstrom
<len-l@xxxxxxxxx>