Re: [pygame] subsurfaces outside of their parents

[Brian Fisher <brian_fisher@xxxxxxx>]

I might have misunderstood Pete, but I got the impression that what he was
suggesting would end up having the exact behavior you describe, except that
the width and height of the subsurface are just for the shared pixel data
area. 

To explain what I mean, some drawing api's have an idea of a
surface/frame/image whatever having an origin other than 0,0 - so like you
might have a source image whose size is 10x10, with an origin of -10,0, so if
you now blit that source image to 0,0 on some destination surface, then the
drawn rect on the destination will be 10,0 to 20,10. Also, if you asked for
the rect of the source image it would return 10,0 to 20,10.

Another way to think of that kind of feature would be there is an offset for
the pixel data from the surface's coordinates.

I think if pygame surfaces had something like this, than you could use it in
the subsurface problem you describe to get the coordinate system you are
asking for, but have a width/height that makes sense.

For example, parent surface is 40x40 origin 0,0. child is
parent.subsurface(-10,10 to 10,10).
The child then has a width/height of 10,10 (because that is the size of the
overlapping area) but it has an origin of -10,-10 (or a pixel buffer offset of
10,10 if you perfer)

so then if you draw to 0,0 of the subsurface, it maps to -10,-10 in the shared
pixel buffer, and it doesn't draw (which is what you'd expect). And if you
draw to 10,10 of the subsurface if maps to 0,0 in the shared pixel buffer,
which draws to 0,0 in the parent (again what you'd expect)

I figure that's a better way to solve the problem than having surfaces that
lie about their sizes or have "dummy" pixels or any of that.

------ Original Message ------
> I want a subsurface to be the size/location that you ask it, even if
> it overlaps/is outside of the parent surface. Any pixels that are
> outside of the surface would be "dummy" pixels and any drawing to them
> would be ignored. The idea is to be able to draw to a surface (0,
> 0)through(10, 10) and on the parent surface have it be drawing (-5,
> -5)through(5, 5), and only (5, 5) --> (10, 10), which is (0, 0)
> through(5, 5) on the parent surface, would actually be drawing to
> non-dummy pixels. This might be really hackish though because what
> then if you were to blit this subsurface to another surface, with its
> dummy pixels? what would the dummy pixels show up as? I guess it
> simply wouldn't copy them... as if you had asked it to blit a smaller
> rect. I am mostly thinking about drawing aspect though...
> 
> On 11/10/05, Brian Fisher <brian_fisher@xxxxxxx> wrote:
> > ------ Original Message ------
> > > No, it needs to appear to be 20x20 because the whole idea is to have
> > > whether or not its off the surface to be transparent. This makes it so
> > > code can draw 0, 0, --> 20, 20 on the subsurface without having to
> > > compensate for being off the surface and such... I want this feature,
> > > personally, for a widget drawing system involving subsurfaces.
> > >
> > That sounds wrong - the whole idea of subsurface is that it shares pixels
with
> > it's parent surface, right? So are you hoping this subsurface call to grow
the
> > parent? are you hoping it would partially share pixels with the parent
and
> > have some of it's own pixels? are you hoping it would have all it's own
pixels
> > and none shared? are you hoping it would just return a false width and
height
> > and really only have shared pixels on the area that did overlap the
parent?
> >
> > ...Because none of those 4 behaviors are something I'd want pygame to do
and I
> > can't think of any other way to resolve the surface having the size you
asked
> > for in the case you describe.
> >
> > ...I really like the modification Pete described though - I agree that it
> > seems to be the right thing, and aside from the fact that nothing would
be
> > drawn to the area that didn't exist on the parent (which seems like the
right
> > thing to me), it appears to satisfy your requirement "to have whether or
not
> > its off the surface to be transparent" in that you can draw from 0,0 to
20,20
> > and have the destination be where you said it should be.
> >
> >
> > > On 11/8/05, Peter Shinners <pete@xxxxxxxxxxxx> wrote:
> > > > On Tue, 2005-11-08 at 00:46 -0500, Forest Darling wrote:
> > > > > I would like to see a feature where you could have a subsurface take
a
> > > > > rect that covered an area that was partially or completely outside
> > > > > parent surface's rect...
> > > > >
> > > > > s = pygame.Surface((100, 100))
> > > > > sub = s.subsurface(Rect(-10, -10, 20, 20)
> > > >
> > > > This has been suggested before. If it is ok for the returned
subsurface
> > > > to be smaller than requested, this would be easy to implement. The
> > > > surface would still use the right offset so that drawing to it would
> > > > appear where you expected.
> > > >
> > > > sub = s.subsurface(Rect(-10, -10, 20, 20)
> > > > print sub.get_size()
> > > > (10, 10)
> > > >
> > > > I'll think about it some more, it can lead to strange cases, but for
the
> > > > most part I think it would do the right thing.
> > > >
> > > >
> > >
> >
> >
> >
> >
>