[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pygame] hooking Surface



On 2003-02-19, Pete Shinners wrote:

> Beni Cherniavsky wrote:
> > So I have a different idea that's more useful than [only] subclassing:
> > allow to set a hook (callback) on a Surface that will be called from the C
> > side with the changed rect after any update to the surface.
>
> i've had thoughts about this as well. but from my perspective i was
> thinking an "automatic dirty/update rectangles" management for the
> display surface would be excellent.
>
I agree - if there will be some generic interface, the most common use of
updating the display should be implemented and provided ready to use.

> the interface could use some potential thinking about. i would expect a
> "full" implementation would allow a program to turn the updates off and
> on for blocks of code, and then perhaps provide its own update data.
>
I was more interested in getting the update data than providing it.
Providing is not a problem currently; getting it is very cumbersome, given
that a surface is an opaque C type and some opaque C functions draw upon
it, without checking if it has some __putpixel__ method (nor should they,
it would be real slow this way).

> this way the internal updating could be fairly 'dumb' and just pass the
> update rectangles as they happen. the programmer could then override the
> behavior, for example when drawing many small primitives (or set_at) in
> a small area.
>
Note that you can easily pass ``Rect().union_ip`` or ``[].append`` as the
callback to effeciently combine/record them.  You can also create a single
callable that will "multicast" the updates to multiple callbacks.  So the
callback approach can easily express other approaches.

I now think that a push/pop interface for setting callbacks will be best.
The last callback is the only active one.  This simplifies temporary
overriding a lot.

> as a side note, the next logical step for this is to move from
> rectangles, to "regions" which would properly deal with overlapping
> areas and nonrectangular shapes. i know windows internally uses regions
> like this to define nonrectangular window shapes.
>
That's a bold move.  Implementing these things is not trivial.  There are
many tradeoffs here, each application would work best with a different
model of regions.  I suggest first to stay with rects for updates.
Parallely, you can invite feedback on what kind of regions interface
people would like to see (after all Rects *are* very convenient), and
gradually add them.

> instead of implementing a callback, i was thinking about simply
> collecting a stack of update rectangles. then you can find out what has
> been updated in any part of your program. although the callback method
> does let you share 'locking' between the drawing and the update.
>
> i'll be thinking about this deeper for a little, and i'm wide open to
> any thoughts on it. the biggest issues i'd want to work smooth are the
> 'automatic display rectangles' and the clean ways to handle "multiple"
> parts of a program interested in these updated regions.
>
I'm not sure I can imagine multiple parts of a program to be interested in
the updated regions of the same surface.  YMMV.  If you do need it, the
callback approach adapts simply (just call many of them) while the
approach or recording and periodically looking at the queue and
clearing it doesn't (each interested party will need a separate poiter
tracking which updates it has already seen and it's not clear when to
discard them).

P.S. Did I say that pygame rocks ?-)
-- 
Beni Cherniavsky <cben@tx.technion.ac.il>

Do not feed the Bugzillas.
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org