Flan: Animations in Flapjax
noel...@gmail.com
Flan:
http://github.com/noelwelsh/flan/
Happy hacking.
N.
Shriram Krishnamurthi
The Fade In works nicely, but unfortunately Slide Down doesn't, at
least not on Firefox 3.0.8 on Windows. Error:
Error: elt.getHeight is not a function
Source File: effects.js
Line: 13
[Heading out of town in the AM, so can't investigate more right now
I'm afraid, but hopefully this is useful.]
Shriram
Noel Welsh
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:
...
> least not on Firefox 3.0.8 on Windows. Error:
Shriram Krishnamurthi
Artyom Shalkhakov
2009/4/17 noel...@gmail.com <noel...@gmail.com>:
> I've just uploaded my (very small, very incomplete) animation library
> Flan:
>
> http://github.com/noelwelsh/flan/
That's great job. :)
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. :(
You can take a look at a somewhat simplified version here:
<http://www.sound-city.kz/fj/flapjax.html>
(doesn't work in IE only because of my laziness)
Also, I've written articles about Flapjax and animation
using Flapjax in Russian:
<http://chiaroscuro.yvision.kz/blog/9161.html>
<http://chiaroscuro.yvision.kz/blog/9169.html>
<http://chiaroscuro.yvision.kz/blog/9468.html>
If anybody is interested, I can as well translate them to English.
The bottom line is: don't overuse animations. :) If one needs a lot
of animation, then they should resort to Flash, I suppose.
Cheers,
Artyom Shalkhakov.
PS sorry for the late reply. I was very busy finishing my first
Flapjax-powered website. :)
Noel Welsh
wrote:
> I have a question: why did you use event streams instead of behaviors?
> Is this because of performance?
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...
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.
(Nice canvas example here: http://vis.stanford.edu/protovis/ex/clock.html)]
> Also, I've written articles about Flapjax and animation
> using Flapjax in Russian:
> <http://chiaroscuro.yvision.kz/blog/9161.html>
> <http://chiaroscuro.yvision.kz/blog/9169.html>
> <http://chiaroscuro.yvision.kz/blog/9468.html>
>
> If anybody is interested, I can as well translate them to English.
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. :)
functional reactive javascript!)
N.
Arjun Guha
> 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):
http://www.cs.brown.edu/~arjun/tmp/table.html
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).
Arjun
Arjun Guha
http://www.flapjax-lang.org/demos/catchup.html
Here's catchup using a different implementation of Flapjax:
http://www.cs.brown.edu/~arjun/tmp/catchup.html
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.
Arjun
Leo Meyerovich
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
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
Leo Meyerovich
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.