[Sugar-devel] What should be the ideal range for animations FPS ?

laurent bernabe laurent.bernabe at gmail.com
Wed Jan 8 16:38:59 EST 2014


I'll try to use the inspector whenever I run into serious animation issue.
Thanks.

Indeed, looks like all this concern seems very difficult without using at
least a tweening library.
Tween.js/Easel.js looks to be a very good one (it is recommanded to use the
ticker function from easel.js, or to write one from scratch), and I am very
interested in developping  activities with it.

But :

   - it does not seem to be AMD-ready : which, I think can be easily
   solved, looking again at Require.js documentation
   - the minified version (about 80 ko) seems to be the only way to avoid
   increasing significantly activity size when using it : again, I think I can
   go for it.

Regards

Laurent Bernabe


2014/1/8 Manuel Quiñones <manuq at laptop.org>

> 2014/1/8 laurent bernabe <laurent.bernabe at gmail.com>:
> >
> >
> > 2014/1/8 James Cameron <quozl at laptop.org>
> >>
> >> On Wed, Jan 08, 2014 at 11:49:56AM +0100, laurent bernabe wrote:
> >> True, but if you make a simple test available, others can test it for
> >> you.
> >>
> >> Especially so if you can figure a way to give the test report on
> >> screen, like a frame rate achieved.
> >
> >
> >
> > If I've well understood, I should give a way to turn on/off the frame
> rate
> > display ?
> > (Like in some games / 3D frameworks).
>
> A display with the current FPS is great for testers.
>
> For your own tests, there are impressive debugging tools in web
> technologies that I never seen before.  The inspector timeline in
> Chrome, for example:
> https://developers.google.com/chrome-developer-tools/docs/timeline
>
> There you can see how much takes your app for painting and for other
> calculations, so you can find the bottleneck in your code.  You can
> even click on a paint record and it will highlight the area of the
> screen that was changed.
>
> >
> >
> >>
> >> Yes, it is not practical to have a suggested range given the number of
> >> variables.
> >>
> >> However, designing for higher values can have benefits ... in research
> >> for Netrek it was found that:
> >>
> >> - five frames per second is a minimum for perception of motion, but
> >>   most users will perceive the steps and use them as the basis for
> >>   their reaction, such that when the rate is increased their training
> >>   has to be redone,
> >>
> >> - ten frames per second is preferable, with most users still
> >>   perceiving the steps,
> >>
> >> - 25 frames per second is very good, with most users not perceiving
> >>   the steps,
> >>
> >> - 50 frames per second is excellent.
> >
> >
> >
> > Thank you very much for this guideleness.
> > So, in my case, I should keep a frame rate around 50, if I really need to
> > fix it myself (I am thinking about the javascript requestAnimationFrame()
> > function).
>
> With requestAnimationFrame you don't force a constant FPS.  Instead,
> the callback is called as fast as your machine can.  So is good to
> decouple the duration of your animation from the frame rate.
>
> If you move your image 2 pixels each frame, the velocity will vary in
> diferent systems.  Instead, you should calculate how many milliseconds
> have passed since the last frame, and move your imave accordingly.
> Here is when interpolation comes into play, and a tweener lib becomes
> handy.
>
> >>
> >> > And also, as I've been told on this mailing list, there is a new
> >> > Javascript API in order to let the computer(web browser ?) hold this
> >> > value for the programmer.
> >> >
> >> > So I think the "issue" can easily be solved : at least with this
> >> > requestAnimationFrame() function.
> >>
> >> Great.
> >>
> >> --
> >> James Cameron
> >> http://quozl.linux.org.au/
> >
> >
> > Regards
> >
> > Laurent Bernabe
> >
> >
> > _______________________________________________
> > Sugar-devel mailing list
> > Sugar-devel at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
>
>
>
> --
> .. manuq ..
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140108/5f8b95f0/attachment.html>


More information about the Sugar-devel mailing list