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@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