[Fieldtrip] Re: [reactive] reactive-fieldtrip

[Eyal Lotem]

Hey, my reply is in the contents:

On Tue, Nov 11, 2008 at 9:57 PM, Conal Elliott <conal at conal.net> wrote:
> Hi Eyal,
>
> Thanks for the comments.  I'm replying on the FieldTrip list rather than on
> reactive, since the issues are mostly FieldTrip issues.
>
> On Tue, Nov 11, 2008 at 7:24 AM, Eyal Lotem <eyal.lotem at gmail.com> wrote:
>>
>> Hi
>>
>> I would also like to congratulate Conal and everyone else involved in
>> the Reactive framework and libraries for the new release.  Amazing
>> work!
>>
>> I have finally managed to do more than read about it, and actually toy
>> with some Reactive programming :-)
>> It seems great fun, and the learning curve is not as steep as it might
>> seem at first.
>>
>> I mostly played with Test.hs inside the reactive-fieldtrip adapter,
>> and I have encountered a few issues:
>>
>> A. It seems that when changing spinningG to scale according to time,
>> it becomes extremely slow very quickly.
>
>
> Probably because of the current algorithm for dynamic tessellation
> (approximation by polygons).  As you scale up, a surface will get
> tessellated more and more finely during rendering.  The tessellations are
> cached in an efficient, infinite, pure data structure (a MemoTrie) as
> they're computed.  Given your experience, I gather there's some tuning
> required.
That sounds possible.  Unfortunately, the behavior I experienced
earlier has disappeared. Now it seems that there are no scaling
problems at all (I don't know what changed, maybe a reboot or other OS
issue).

As for the "lplace" example, the only issue that is still left is that
clicks are still handled with a delay of about 1 second.
Additionally, the window coordinates that are used seem to be naively
mapped to 3d coordinates that are not correct, though that is
intentional.

>> B. The lplace demo itself is also extremely slow, whereas other demos
>> seem to be fine/quick. It might be buggy, and not extremely slow, its
>> taking so long to react that I am not sure what is happening.
>
>
> All of the demos are *very* zippy on my machine, even with 10-20 spinning
> torus pairs going.
It seems OK here now too.

> Could you please give me particulars about your setup?  For instance:
> cpu(s), graphics card, OS, and versions of opengl & glut.
While the issues are gone now, they were there earlier so they might
help identify a pattern. The setup is:

Ubuntu Intrepid
CPU=AMD Athlon(tm) 64 Processor 3500+
GeForce=05:00.0 VGA compatible controller: nVidia Corporation G70
[GeForce 7600 GS] (rev a1)

OpenGL = NVidia GLX
nvidia-glx-177    177.80-0ubuntu3  NVIDIA binary Xorg driver

dpkg -l freeglut3
freeglut3  2.4.0-6.1

GHC: The Glorious Glasgow Haskell Compilation System, version 6.10.0.20081007

>
>> C. Stylistic question/comment:
>> The (Anim a) type (UI -> Behavior a) is a Reader
>> Functor/Applicative/Monad.  I see it used as a Functor in various
>> examples, but it seems that there's no use of the Applicative/Monad of
>> the reader, is this intentional?
>> I find it a bit awkward that it passes the "env" arg to all of the
>> stuff its combining... The example even used an undefined error value
>> in place of the env in some cases, suggesting that it is a burden to
>> pass it around.   Why not encourage the implicit passing of the env
>> everywhere via the reader Applicative?
>
>
> Fixed now.  Thanks.
>
> Regards,  - Conal
>

Eyal