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

Re: [pygame] PixelArray question



On 8/23/07, Marcus von Appen <mva@xxxxxxxxxxxx> wrote:
> On, Thu Aug 23, 2007, Brian Fisher wrote:
> > On 8/22/07, Marcus von Appen <mva@xxxxxxxxxxxx> wrote:
> No - separate purposes are best dealt with in separate, non-interfering
> cases. As you clearly state later on in your mail, PixelArray serves a
> complete own need with a completely own (currently only a minimum)
> function set.
>
Sure, I don't disagree with the principle really.. it's a good
principle. The problem I suppose is how you (and whether you) define
"seperate purposes". For instance, you could say blitting to a surface
is a "seperate purpose" than having one, in which case you wouldn't
make the surface have a blit function (some graphics api's are in fact
that way). So that principle in and of itself isn't sufficient to have
a meaningful discussion of the best way to structure an api (because 2
people could easily apply the same principle and get dramatically
different results)

> My short- to midterm goals are full mapping support (array[x1:x2, y1:y2]
> ...), maybe the one or other fast manipulation function and whatever
> else might fit. Putting all this functionality directly into the Surface
> does not seem appropriate to me.
>
Does full mapping support mean that:

PixelArray[10:20][10:20]

would give you a new 10 x 10 PixelArray that is a subset of the
original, or does it mean more than that?

So what's fast manipulation function? Does that mean like inplace ops?
Numeric style arithmetic magic?



> [...PixelArray might just be redundant...]
> > ...however keeping PixelArray as a seperate object but hiding it as an
> > "interface" would still serve the same goals
>
> How would the interface look like in your opinion?
>
Basically it would be that you would provide buffer access operations
on the surface, which would return a PixelArray object in the case of
slicing.

So basically this:
        sf = pygame.Surface ((10, 20))
        sf.fill ((0, 0, 0))
        ar = pygame.PixelArray (sf)

        ar2 = ar[0]

would become this:
        sf = pygame.Surface ((10, 20))
        sf.fill ((0, 0, 0))
        ar2 = sf[0]

and would be functionally identical in terms of the behavior of sf & ar2
Another way to think of it would be that buffer access on the surface
would construct a PixelArray, and you wouldn't have to bother with the
PixelArray constructor.

The advantages as I see it are:
1. you type less when you know how to do stuff
2. If you construct a PixelArray from a surface, it's not clear at all
that it's data and functionality are intertwined with the Surface's
content. However if you get a PixelArray through buffer/slicing
access, It is fairly clear that ar2 is actually meaningfully
intertwined with sf's data (because you got it as being an element of
the surface)
3. It's kind of what someone completely fresh to the problem would
expect to be able to

The possible disadvantages that I see are:
1. It's kind of what someone completely fresh to the problem would
expect to be able to... but it may not be signficantly differently
from what they'd expect to be able to do in?
2. There may be some design and implementation issues with it that
someone who actually wrote PixelArray could see... ?


> > So I think the answer to why it couldn't be part of surface is slicig
> > & automagic managing or surface locking...
>
> And the completely different funcitonality purpose ;-).
>
Tomatoes, Tomatoes. :)