[GEM-dev] musings on multiple_window

[IOhannes m zmoelnig]

james tittle wrote:
> On Feb 2, 2005, at 3:46 AM, IOhannes m zmoelnig wrote:

>> yes, timing.
>> i guess it would/could/should be possible to somehow handle 
>> [gemcontrol]s at different rates, e.g. only render once a second into 
>> a pbuffer (or even better: on demand!)
>>
>> how do we handle this efficiently ? (esp. with respect to "time-based" 
>> objects, like [pix_movie] in auto-mode or particle-systems)

probably the question should be: "how do we handle this at all ?"

> 
> 
> ...have to admit I haven't looked much at this, but I will:  what are 
> the likely situations that could trip us up?

the simplest situation: when time-based objects (eg particle-systems, i 
think pix_film (at least on osX (good work!)) does not has this 
problem), just increment their internal time when getting "rendered" by 
a value somehow derived from the current frame-rate (if i remember 
correctly);
now if we have 2 windows, an object's render()-method might get called 2 
times per frame (once for each window), which would double increment the 
internal time, leading to (appearent) double speed.
currently this problem is solved by compiling the scene into 
display-lists and just calling these repeatedly (which does not affect 
any internal time-measurement); however, this is likely to _not_ work 
under certain circumstances (e.g. i jsut discovered that on linux, you 
cannot render simultaneously into a local window and a remote window the 
way it is implemented right now)

but  (see below)

> ...otoh, couldn't we duplicate what is done now i pix_film?  I mean, 
> it's possible atm to run one film in auto-mode, and another in 
> metro/"by-the-frame" mode:  wouldn't this be our solution?

i seldomly use [metro] to run a [pix_film] in "by-the-frame" mode, since 
the jitter is quite high. instead i get my timing directly from the 
render-clock (with a [t a b]).


all these problems would not occur, if the render clock would not be 
exposed to pd's message system. however, i do not really want to go back 
to the old behaviour (e.g. use [render_trigger] instead of [t b a b])

furthermore, similar problems arise, if we want to do the rendering in a 
separate thread (which i do want somewhere in the future)




mfg.asd.r
IOhannes