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