[PD-dev] Re: garray_update

[Miller Puckette]

Hi Tim,

Well, forking the source wasn't my idea... I knew it would cause trouble.

In general, the question of scheduling graphics updates is hard, especially
now that (arrays can contain (lists that contain (arrays of scalars))), etc.
Having "garrays" separate from the "real" data structure mechanism was
always a temporary measure, and now I'm glad it's gone.  But what this
means is that now we need a more general way of updating changes to data.
If I can think of a good one I'll get it into 0.39 (it's prety high on
the dolist at the moment...)

cheers
Miller

On Thu, Jun 30, 2005 at 03:19:30PM +0200, Tim Blechmann wrote:
> hi miller, hi devs,
> 
> miller, as you probably know, thomas grill has added a function
> garray_update to devel (probably back in the pd-0.36 days ... it's in
> there since i'm working with pd)
> this function adds a timestamp of the last redraw to the t_garray
> struct in order to throttle array redraws (since as we all know, they
> are not really fast).
> 
> well, porting them to devel_0_39, i figured out that accessing the
> t_garray in the array_motion() function is not really easy any more,
> which basically means, thomas or me, one of us has to rewrite this
> again. or we loose this feature again!
> 
> miller, please try to keep an eye on devel to make sure, that you don't
> break any features added there. this is one example showing that
> developing with two parallel branches doesn't really work and just
> causes a lot of trouble.
> 
> cheers ... tim
> 
> -- 
> mailto:TimBlechmann at gmx.de    ICQ: 96771783
> http://www.mokabar.tk
> 
> latest mp3: kMW.mp3
> http://mattin.org/mp3.html
> 
> latest cd: Goh Lee Kwang & Tim Blechmann: Drone
> http://www.geocities.com/gohleekwangtimblechmannduo/
> 
> After one look at this planet any visitor from outer space 
> would say "I want to see the manager."
> 				      William S. Burroughs