Use requestAnimationFrame throttling queues etc. making room for UI/GC

[raix]

When working with apps using a lot of UI animation we have to make sure Meteor makes room for UI and the GC - otherwise we will get a laggy user experience.

Areas where we should look at using requestAnimationFrame:

• setTimeout (ref: https://github.com/Famous/famous/blob/master/src/utilities/Timer.js#L60)
• setInterval (ref: https://github.com/Famous/famous/blob/master/src/utilities/Timer.js#L84)
• the ddp message queue in Meteor

Leads?:

• https://github.com/meteor/meteor/blob/devel/packages/ddp/livedata_connection.js#L453)

Maybe have a way to create a throttled each function?

Ref: https://github.com/gadicc/meteor-famous-views/commit/ee52b8868eb34044af942ca15b1450ddba7c59ad#commitcomment-8674787 https://github.com/CollectionFS/Meteor-CollectionFS/issues/106#issuecomment-32707630

[gadicc]

Excellent point! This is going to be a big one for us (famous-views) moving forward. There are two issues:

• Being able to specify an alternate way of deferring, e.g. if we're in a famous app, we'd like Meteor and Meteor.defer to use famous.core.Engine.defer (which throttles it's queue instead of Meteor's setImmediate polyfill -- to make sure deferred events don't fire at an inconvenient time and block the animation queue.
• Yeah, unfortunately we'd need a way to cap execution time of stuff, and if that cap will be exceeded, queue and defer the rest and do it bit by bit. Not something to look forward to, but it's going to be important. We'll assist where we can to find the biggest bottlenecks, each could indeed be a problem.

Thanks, @raix!

[gadicc]

Can we rename to "Throttled queues, custom defer, etc to accomodate UI & GC" ? requestAnimationFrame doesn't always help depending on what else is going on, e.g. famo.us assumes / relies on the fact that it's the only thing using it.

[PEM--]

:+1: If we want the web to win, we need smoothness and animated effect. Very needed.

[raix]

FYI: We have just written a small Kernel for administrating the animationFrame - lets you run functions in frame or when theres cpu time. It also have a defered each that lets you iterate over collections when theres cpu time - similar to famous Engine actually.

• It replaces the Tracker.autorun - this flattens out spikes in the timeline caused by reactivity - And helps us keep stable 60fps. Not sure if we can hook further into some of the queues running ddp.

cc. @avital

[mitar]

jQuery removed support for requestionAnimationFrame some time ago. It might be good to read their rationale and see if it applies.

[mitar]

(In general I would say that not all Tracker.autorun calls should not be called when the window is in the background.)

[raix]

Yeah, makes sense to have setTimeout and setInterval use requestanimationframe. Autorun could check if computation is already in defered queue.

[gadicc]

@raix, sounds awesome! sorry, i'm still catching up stuff my holiday from the internet :> who is "we" and can you give a link to the code?

[raix]

@gadicc yeah, saw you taking a break :) I'm freelancing for a company in Boston at the moment, hope to release some packages soon - I tested iscroll and famous scroll, but none had the performance we needed, so we did a reactive infinite scroller to keep above 60fps - the kernel helped flattening out reactive update spikes (its sort of using blaze to render the html)

@mitar thanks for the heads up, I've added a defered limit - but one could reason more about this stuff - If I only had the time.

[gadicc]

@raix, was definitely an amazing break... I highly recommend them :>

Very cool. And awesome that you'll be able to release some stuff as open source.

Do you think it will be useable with Famo.us? It seems like since Famous does it's own management, might be best in that case to use your logic for rewriting Tracker.autorun but simply plug it in to Famo.us Engine.defer? What do you think?

Also as per @mitar's comment, I think it would be good to process the queue via setTimeout too. We could set a timeout in every frame, for say, 1s, and cancel on the next frame -- to detect when requestAnimationFrame is no longer running. I'd go so far as that everything in Tracker.autorun() should by default, still run in the background... but it would definitely be cool to give the dev the choice and handle the queues accordingly. I'll also take a look at all this soon, it's exciting :>

[raix]

I've never tried a break before, but since you recommend it I should at somepoint :)

famous.core.Engine have a similar api for defering functions - you could write a Tracker.autorun specific for famous.

For setTimeout etc. check out the utils in famous - they have this already - so they are on the right track.

its released - dispatch:kernel - just tested it on an other mobile app, improves overall startup ui response - nice.

The famous Engine lacks the defer limit - so it could potentially fail as jquery did? I'm not using famous, I'm giving it 2 years before we can start relying on it - due to api changes + mobile support. (at the moment I'm considering famous a good pattern)

We use dispatch:interpolator (also public) - its a small api helping with basic animations.

EDIT: The interpolator is for animation where 100% control is needed - its used only for specific things that need this.

All credit goes to @DispatchMe cc. @jperl

[gadicc]

Brilliant! Many thanks.

Yeah, Famo.us still has some way to go but I like the direction they're going in, and it's exciting to get proficient at frameworks early sometimes, even when there is accompanying pain - like with Meteor.

I agree. I think if the project is using Famo.us, then Famo.us should be responsible for time/frame management, and then, it's the role of an integration library like famous-views to make sure Meteor works with that properly. I'll have to look into it more, but yeah, it could have all those issues, but those are issues they'll have to solve regardless, so I think it's all good - from my side at least :)

Thanks for the all the info and repos! And to @DispatchMe for their attitude and contribution.