Slide Down depends on prototype.js, which I hadn't uploaded to Git. I
have done so now, so that effect should work. (You also need
flapjax.js in the same directory, but I guess you have that already.)
For anyone trying Flan on IE, note that Fade probably won't work.
N.
On Apr 18, 2:57 am, Shriram Krishnamurthi <s...@cs.brown.edu> wrote:
...
> The Fade In works nicely, but unfortunately Slide Down doesn't, at
> least not on Firefox 3.0.8 on Windows. Error:
I have a question: why did you use event streams instead of behaviors? Is this because of performance?
I looked at a wide variety of javascript animation libraries out there, and it seems like they all eat CPU like candies. What is interesting here is the fact that the results of profiling code samples that I posted before indicate that DOM updates are inefficient, and it looks like there's nothing we can do about that...
For example, it turned out that an assignment to window.location.hash is so slow that I had to "isolate" it in a setTimeout(fun,0). That doesn't help much, ewww. :(
On Apr 30, 10:38 am, Artyom Shalkhakov <artyom.shalkha...@gmail.com>
wrote:
> That's great job. :)
Thanks!
> I have a question: why did you use event streams instead of behaviors?
> Is this because of performance?
I used event streams as they seemed natural at the time. So, no good
reason. Behaviors might be better.
> I looked at a wide variety of javascript animation libraries out there,
> and it seems like they all eat CPU like candies. What is interesting
> here is the fact that the results of profiling code samples that I
> posted before indicate that DOM updates are inefficient, and it
> looks like there's nothing we can do about that...
Yes, I don't think current browsers are the right tool for complex
animations. I'm more interested in building user interface widgets,
like grid and table controls, and using animations to provide simple
visual feedback to the user.
[I think some browsers might be capable of complex animations. For
example, it seems you can do quite a lot with the canvas in recent
versions of Firefox, but this of course doesn't work in IE.
> If anybody is interested, I can as well translate them to English.
I'm happy with the current documentation (and reading the source
code), but I imagine I'm the exception given my experience with the
work preceding Flapjax. I imagine English translations would get more
traffic.
> PS sorry for the late reply. I was very busy finishing my first
> Flapjax-powered website. :)
Excellent! (And interesting to see Kazakhstan leading the world in
functional reactive javascript!)
> Yes, I don't think current browsers are the right tool for complex > animations. I'm more interested in building user interface widgets, > like grid and table controls, and using animations to provide simple > visual feedback to the user.
I think this is the right. I believe that UI widgets are significantly harder than animations and push the language and its abstractions much further
I thought I'd give a simple data grid a shot (Safari 4, Firefox 3):
There are some inefficiencies I've noted in the source. In addition, the code would be a lot cleaner if we had a generalized version of tagRec that worked with multiple elements.
In this grid, I care about clicks on the <table> and keyboard events on the <textarea>. The structure of the <table> is dependent on enterKeyE's on the <textarea>. Since tagRec just works with a single element, I had to use sendEvent (table.js:128).
It should feel smoother. Specifically, in the old catchup, if you move the mouse fast, the word "up" gets frozen in place, and moves around erratically.
With the new Flapjax, "up" should freeze a lot less.
Technical details:
The problem with catchup is the use of timerB and delayB: popular functions for animations. timerB and delayB are implemented with JavaScript's setInterval and setTimer. When you move the mouse really fast, the flurry of UI events supersede the scheduled setTimer/setInterval events, so the delayed "up" gets stuck. We talk about "glitches" in a single timestep. IMO, this is a glitch-like thing.
I've reimplemented the scheduler so that events can be scheduled for the future. delayB no longer creates a new callback for each event. Instead it simply schedules them for the future.
What we have now is just a reimplementation of delayB and a new scheduler. If this looks promising, I'll go ahead and fix timerB. As I see it, timerB, delayB and other such functions would all just schedule events for the future. Flapjax would have a single setInterval timer callback whose resolution would be the minimum resolution used by the program.
1. Often, the schedule gets behind because of lack of computational resources. For animation, it's more important to be on the absolute schedule than to show every frame (your fix preserves frames in the 'right' order, but it can still get behind in terms of wall-time). I had tried my hand at monitoring FPS and dropping frames in animation code when this occurred. E.g., animation_timer(min, max, fps) goes from min to max in fps, but may skip inbetween values of it isn't hitting the desired framerate. This was done cooperatively with concurrent timers. Unfortunately, it was also noticeably slower in my initial attempt :)
2. There's s FFI question for sendEvent:
The new way for external libraries to inject events is "sendEvent(event, source, when)". If we want multiple external events to be in the same timestep (to prevent glitches), because sendEvent calls propagatePulses which calls date().getTime(), we can lose this glitch-freedom. I can see coders tempted to use 'when' for this, but that's not reliable. There should be a glitch-free interface (multiple calls to sendEvent in a step should get batched -- think Esterel).
A subtlety here is that I'm assuming sendEvent is asynchronous so it's possible to express this to beginwith (atm, it is not).
> It should feel smoother. Specifically, in the old catchup, if you
> move the mouse fast, the word "up" gets frozen in place, and moves
> around erratically.
> With the new Flapjax, "up" should freeze a lot less.
> Technical details:
> The problem with catchup is the use of timerB and delayB: popular
> functions for animations. timerB and delayB are implemented with
> JavaScript's setInterval and setTimer. When you move the mouse really
> fast, the flurry of UI events supersede the scheduled
> setTimer/setInterval events, so the delayed "up" gets stuck. We talk
> about "glitches" in a single timestep. IMO, this is a glitch-like
> thing.
> I've reimplemented the scheduler so that events can be scheduled for
> the future. delayB no longer creates a new callback for each event.
> Instead it simply schedules them for the future.
> What we have now is just a reimplementation of delayB and a new
> scheduler. If this looks promising, I'll go ahead and fix timerB. As
> I see it, timerB, delayB and other such functions would all just
> schedule events for the future. Flapjax would have a single
> setInterval timer callback whose resolution would be the minimum
> resolution used by the program.
We lack a good demo that truly taxes Flapjax and the web-browser's
speed. Perhaps it's time to write pong, 3-body simulators, etc.
They're easy to express in FRP but they exercise the speed of our
implementation.
I suspect the new scheduler will be particularly good for programs
that make many calls to timerB and delayB: it will be be great for
composing animations and interfaces.
On Thu, May 7, 2009 at 13:54, Leo Meyerovich <lmeye...@gmail.com> wrote:
> Ha, nice :)
> Two further thoughts:
> 1. Often, the schedule gets behind because of lack of computational
> resources. For animation, it's more important to be on the absolute
> schedule than to show every frame (your fix preserves frames in the
> 'right' order, but it can still get behind in terms of wall-time). I had
> tried my hand at monitoring FPS and dropping frames in animation code
> when this occurred. E.g., animation_timer(min, max, fps) goes from min
> to max in fps, but may skip inbetween values of it isn't hitting the
> desired framerate. This was done cooperatively with concurrent timers.
> Unfortunately, it was also noticeably slower in my initial attempt :)
> 2. There's s FFI question for sendEvent:
> The new way for external libraries to inject events is "sendEvent(event,
> source, when)". If we want multiple external events to be in the same
> timestep (to prevent glitches), because sendEvent calls propagatePulses
> which calls date().getTime(), we can lose this glitch-freedom. I can see
> coders tempted to use 'when' for this, but that's not reliable. There
> should be a glitch-free interface (multiple calls to sendEvent in a step
> should get batched -- think Esterel).
> A subtlety here is that I'm assuming sendEvent is asynchronous so it's
> possible to express this to beginwith (atm, it is not).
> - Leo
> Arjun Guha wrote:
>> I'm trying to make animations a bit better. You've seen the catchup demo:
>> It should feel smoother. Specifically, in the old catchup, if you
>> move the mouse fast, the word "up" gets frozen in place, and moves
>> around erratically.
>> With the new Flapjax, "up" should freeze a lot less.
>> Technical details:
>> The problem with catchup is the use of timerB and delayB: popular
>> functions for animations. timerB and delayB are implemented with
>> JavaScript's setInterval and setTimer. When you move the mouse really
>> fast, the flurry of UI events supersede the scheduled
>> setTimer/setInterval events, so the delayed "up" gets stuck. We talk
>> about "glitches" in a single timestep. IMO, this is a glitch-like
>> thing.
>> I've reimplemented the scheduler so that events can be scheduled for
>> the future. delayB no longer creates a new callback for each event.
>> Instead it simply schedules them for the future.
>> What we have now is just a reimplementation of delayB and a new
>> scheduler. If this looks promising, I'll go ahead and fix timerB. As
>> I see it, timerB, delayB and other such functions would all just
>> schedule events for the future. Flapjax would have a single
>> setInterval timer callback whose resolution would be the minimum
>> resolution used by the program.
The one I had done it for was more typical: a bunch of menu buttons that highlight and fadeout when you mouse over. Imagine a lightgrid or something. You can imagine something similar with the twit map (as events come in, show them).
My junky version was for the old 22 website; I'll try to dig it up after work.
Arjun Guha wrote:
> We lack a good demo that truly taxes Flapjax and the web-browser's
> speed. Perhaps it's time to write pong, 3-body simulators, etc.
> They're easy to express in FRP but they exercise the speed of our
> implementation.
> I suspect the new scheduler will be particularly good for programs
> that make many calls to timerB and delayB: it will be be great for
> composing animations and interfaces.
> Btw, the animationTimerB is a great idea.
> Arjun
> On Thu, May 7, 2009 at 13:54, Leo Meyerovich <lmeye...@gmail.com> wrote:
>> Ha, nice :)
>> Two further thoughts:
>> 1. Often, the schedule gets behind because of lack of computational
>> resources. For animation, it's more important to be on the absolute
>> schedule than to show every frame (your fix preserves frames in the
>> 'right' order, but it can still get behind in terms of wall-time). I had
>> tried my hand at monitoring FPS and dropping frames in animation code
>> when this occurred. E.g., animation_timer(min, max, fps) goes from min
>> to max in fps, but may skip inbetween values of it isn't hitting the
>> desired framerate. This was done cooperatively with concurrent timers.
>> Unfortunately, it was also noticeably slower in my initial attempt :)
>> 2. There's s FFI question for sendEvent:
>> The new way for external libraries to inject events is "sendEvent(event,
>> source, when)". If we want multiple external events to be in the same
>> timestep (to prevent glitches), because sendEvent calls propagatePulses
>> which calls date().getTime(), we can lose this glitch-freedom. I can see
>> coders tempted to use 'when' for this, but that's not reliable. There
>> should be a glitch-free interface (multiple calls to sendEvent in a step
>> should get batched -- think Esterel).
>> A subtlety here is that I'm assuming sendEvent is asynchronous so it's
>> possible to express this to beginwith (atm, it is not).
>> - Leo
>> Arjun Guha wrote:
>>> I'm trying to make animations a bit better. You've seen the catchup demo:
>>> It should feel smoother. Specifically, in the old catchup, if you
>>> move the mouse fast, the word "up" gets frozen in place, and moves
>>> around erratically.
>>> With the new Flapjax, "up" should freeze a lot less.
>>> Technical details:
>>> The problem with catchup is the use of timerB and delayB: popular
>>> functions for animations. timerB and delayB are implemented with
>>> JavaScript's setInterval and setTimer. When you move the mouse really
>>> fast, the flurry of UI events supersede the scheduled
>>> setTimer/setInterval events, so the delayed "up" gets stuck. We talk
>>> about "glitches" in a single timestep. IMO, this is a glitch-like
>>> thing.
>>> I've reimplemented the scheduler so that events can be scheduled for
>>> the future. delayB no longer creates a new callback for each event.
>>> Instead it simply schedules them for the future.
>>> What we have now is just a reimplementation of delayB and a new
>>> scheduler. If this looks promising, I'll go ahead and fix timerB. As
>>> I see it, timerB, delayB and other such functions would all just
>>> schedule events for the future. Flapjax would have a single
>>> setInterval timer callback whose resolution would be the minimum
>>> resolution used by the program.
|
