[plt-scheme] FrTime implementation

Hi Dave,

Sorry.  I forgot that do-in-manager-after already waits for FrTime to
finish processing, so the channels are unnecessary (and will cause a
deadlock).  The loop code can just read:

(let loop ()
 ;; emit the next pulse
 (send-event fluxus-pulse #t)
 ;; wait for frtime to finish updating everything
 (do-in-manager-after (void))
 ;; draw the frame from a consistent state
 (draw-a-frame <reactive scene description data structure>)
 (loop))

Greg

On Jan 12, 2008 9:31 AM, Dave Griffiths <dave at pawfal.org> wrote:
> Hi Greg,
>
> I've had a go at implementing this, and it seems to hang inside
> (do-in-manager-after (channel-put frtime-chan #t))
> Presumably because the channel-put is being run straight away and
> blocking rather than being deferred... I looked at the macro but got a
> bit lost :)
>
> My code is still very trivial (mostly copy pasted from your email):
>
> (module frtest mzscheme
>
>   (require
>    (lib "lang-ext.ss" "frtime")
>    (all-except (lib "frp-core.ss" "frtime") undefined?))
>
>   (provide
>    set-scene
>    clock)
>
>   (define frtime-chan (make-channel))
>   (define fluxus-pulse (event-receiver))
>   (define scene-list '())
>
>   (define (set-scene s)
>     (set! scene-list s))
>
>   (define clock
>     (hold
>      (map-e
>       (lambda (e)
>         (current-milliseconds))
>       fluxus-pulse)))
>
>   (define (draw-a-frame lst)
>     (for-each
>      (lambda (b)
>        (display (value-now b))(newline))
>      lst))
>
>   (define (loop)
>     ;; emit the next pulse
>     (send-event fluxus-pulse #t)
>     ;; have frtime send a message when it's done updating everything
>     (do-in-manager-after (channel-put frtime-chan #t))
>     ;; wait for the message from frtime
>     (channel-get frtime-chan)
>     ;; draw the frame from a consistent state
>     (draw-a-frame scene-list)
>     (loop))
>
>   (thread (loop))
>
>   )
>
> (require frtest)
>
> (set-scene (list clock))
>
>
>
> On Sun, 2007-12-09 at 06:43 -0500, Gregory Cooper wrote:
> > Ah.  Now I think I understand the problem a bit better.  It sounds
> > like what you'll want is a mechanism for synchronizing FrTime and the
> > Fluxus render loop.  Here's how I'd recommend doing it:
> >
> > 1.  Define an event stream called something like fluxus-pulse:
> >
> >   (define fluxus-pulse (event-receiver))
> >
> > 2.  Define your own versions of the primitive input behaviors you
> > need, which only update on these pulses.  E.g.:
> >
> >   (define clock (hold (map-e (lambda (e) (current-milliseconds)) fluxus-pulse)))
> >
> > 3.  Each time through the render loop, emit a pulse, then wait for
> > FrTime to stabilize, and finally draw.  Here's a rough sketch:
> >
> > (define frtime-chan (make-channel))
> >
> > (let loop ()
> >   ;; emit the next pulse
> >   (send-event fluxus-pulse #t)
> >   ;; have frtime send a message when it's done updating everything
> >   (do-in-manager-after (channel-put frtime-chan #t))
> >   ;; wait for the message from frtime
> >   (channel-get frtime-chan)
> >   ;; draw the frame from a consistent state
> >   (draw-a-frame <reactive scene description data structure>)
> >   (loop))
> >
> > 4.  Note that with this approach, there is no lifting at all
> > (regardless of DrScheme version).  Instead, as you traverse the
> > reactive structure, you'll just test whether each value you encounter
> > is a behavior, and if so, you'll call "value-now" on it before
> > proceeding.
> >
> > Let me know whether this helps or not.
> >
> > Cheers,
> > Greg
> >
> > On Dec 9, 2007 5:57 AM, Dave Griffiths <dave at pawfal.org> wrote:
> > >
> > > On Sat, 2007-12-08 at 22:52 -0500, Gregory Cooper wrote:
> > > > Hi Dave,
> > > >
> > > > It looks like you have the right idea.  :-)
> > > >
> > > > Are you running a pre-v371 version of DrScheme / FrTime?  (From the
> > > > code and description you give, it sounds like you are...)  I ask
> > > > because around July I changed the way FrTime deals with lists and
> > > > other data structures, and this change makes it a bit more complicated
> > > > to lift over data structures containing behaviors.
> > > >
> > > > In pre-v371, all data constructors (including "cons") are lifted, so
> > > > any reactivity inside a data structure spreads to the structure
> > > > itself.  When you lift a procedure over a reactive structure, the
> > > > procedure gets called repeatedly with snapshots of the structure
> > > > (computed each time anything inside the structure changes).  This is
> > > > why the second (make-torus ...) gets redrawn every millisecond, even
> > > > though it only changes once a second: draw-list processes the entire
> > > > list whenever anything inside it changes.
> > > >
> > > > In v371 and later, data constructors are not lifted, so behaviors can
> > > > hide inside structures.  In order to lift over such structures, you'll
> > > > first need to use "raise-reactivity" to make the reactivity spread to
> > > > the top of the structure, or use "compound-lift" (like the new
> > > > animation.ss does), which lets your procedure find the reactivity
> > > > while traversing the structure.  (This avoids the work of constructing
> > > > a deep snapshot each time something changes.)  If you decide to
> > > > upgrade to v371 at some point, let me know and I'll be happy to help
> > > > explain this.
> > >
> > > That makes sense. I'm running 370 - time to upgrade :)
> > >
> > > > A couple of small comments: I'm surprised that you don't have code to
> > > > clear the buffer before rendering the list of shapes, like
> > > > animation.ss does.
> > >
> > > This is the nub of the problem for me really ;)
> > >
> > > When running in drscheme, the render loop is running in a different
> > > (plt) thread.
> > >
> > > This is due to the way fluxus works - you don't drive the render loop
> > > yourself, but you can optionally hook into it to get a function called
> > > by the engine every frame to animate/update things. (using frtime even
> > > this wont be needed)
> > >
> > > This is a Good Thing - the framerate can be detached from the script
> > > update (you can always interactively move the camera around with the
> > > mouse etc)
> > >
> > > The problem with this naive frtime script is that the primitives strobe
> > > as they are drawing once per millisecond, rather than once per frame.
> > > This is fixed by using retained mode primitives (rather than the
> > > immediate mode (draw-*) ones it uses at the moment), which are
> > > maintained inside the render engine and rendered every frame for you,
> > > optimised for speed. then frtime can just update them whenever it wants
> > > to.
> > >
> > > This has implications to how I implement the frtime interface - I'll
> > > need to do some work to make this stateful (for reasons of speed)
> > > situation appear stateless.
> > >
> > > One option is to require the 'user' to name each object, so the frtime
> > > implementation can infer some historical information - first time it
> > > appears build it, other times update it, when it doesn't appear in the
> > > list delete it.
> > >
> > > How does animation.ss cope with this? If a shape only updates once a
> > > second, how does it get redrawn when other things are updating more
> > > quickly?
> > >
> > > > Also, I'm not sure why you don't just write:
> > > >
> > > >   (define clock milliseconds)
> > >
> > > Ah, I was just playing with changing it, but left it as * 1 :)
> > >
> > > cheers,
> > >
> > > dave
> > >
> > >
>
>