For that we need to change option to advanced_optimization and compile js files together, not separately, like we do today. This is needed as this optimization level renames external functions and globals. That means we need to compile all the libraries we depend on together with Urbini code. Also, we need to define globals we use and all the code called from templates as externs.

This issue has been well understood in Games. Stefan (creator of cannon.js and p2.js) brought my attention to bullet physics engine, which addresses this issue. Here is their doc, and a discussion on this topic that illuminates the problems one developer was having and introduces the term temporal aliasing.

Steven Witten addresses this problem in his amazing webgl-ed slides on the topic of employing math to more close matching physical world in our animations, by creating what human brains are expecting to see, not just clean bezier curves, and along the way compensate for bumps on the road (caused by GC, background apps, user actions). All of this is to achieve a buttery-smooth life-like animation, or an illusion thereof. Fascinating presentation! If I understood Steven correctly, he does not just do temporal aliasing, he is also adjusting the animation path, to create an illusion for the user that the body was moving along the projected path in a gradual manner.

Today we only minify js files, using Google Closure compiler. We need to do that for css as well. Server-side code today uses yuicompressor for css in runtime. We need to move this to a build and use cssmin or csso. Creator of Csso claims it to be far more advanced.

We implemented the world in the web worker. The main thread (renderer) is stepped by a requestAnimationFrame (raf). How should the world be stepped?

1. move them synchronously. Raf issues postMessage to worker to step the world.
2. move them independently. Use a timeout in the worker with interval 1000/60. May be interval needs to be a 1000/(60*2)
3. move them independently but do not let the world to go ahead too much. Not sure I understand this solution but it is what cannon.js does in this example

This issue may depend on the design of #4 for variable timeframe physics.

2D Games have been using parallax effect to create a depth of field feeling. Web sites recently started to use this technique. Some mobile apps do that too. See for example Pandora using content as a layer that is closer revealing menu in a background that is moving as well (note menu text changing its distance to the edge):

There seems to be a simple way to create parallax with css (and it works fast as actual transformations are performed by the GPU):

1. give depth to brick on Z axis, e.g.:
   translateZ: -30px
2. set perspective on a container:
   -webkit-perspective: 500; -webkit-perspective-origin: 0 0;
3. change perspective origin on a container as we scroll/transition:
   container.style.webkitPerspectiveOrigin = scrollXdelta + "px " + scrollYdelta + "px";

So, how does one utilize physics engine to help with this, or do we need to do it outside of it?

Nice and smooth in Safari and Chrome

Firefox is on the right in the screenshot

http://tradle.io/app/Tradle/list/commerce/trading/Tradle?owner=_me&-ref=32341

currently sliding window for infinite scrolling is implemented on a side of the layout manager. It is like a snake (or a worm) that is growing towards its tail while its head is being continuously trimmed as tail grows. The tail could grow a bit faster, so snake is elongated, but eventually the trimmer cuts the head. At the end of the content, the tail is cut short, so snake is at its shortest. The same procedure repeats in reverse when scrolling back. This algorithm is complex and it feels like some physical paradigm could reflect it better than a handcoded algo. Ideas?

Right we do not add a body corresponding to navbar to the world (physics engine's view of the UI). That means we also can not do cool things with it, move it, bump it, morph it, hide it, unhide it with the natural physic-y animations. But when we add navbar to the world, we will need to rethink how scroll bounces off of it.

This issue has been discussed over email and I will try to summarize the ideas my Ellen, Mark and me below. All the work so far was done with physics.js. Great thanks to its creator Jasper for lending his expertise and suggesting ways to use his physics.js for momentum scrolling with bounce.

Problem

Scroller needs to freely move the contents of the page until the tail of the content reaches the edge of the scroll areas (not edge of the screen, as we need fixed top and bottom headers). When the tail of the scrolled content passes the edge it needs to bounce back to the edge and move a bit past it (and repeat the bounce with the smaller amplitude). We need a physical world model for such behavior. A constraint does not work here as it will prevent the movement in both directions. We need this to work for both vertical scrolls and for the horizontal scrolls, like the photo strip inside the page, like in IMDB app they let user scroll movie shots horizontally while still standing on a movie page.

Once implemented we will use it also for a mobile drawer (left/right side menu) transition, and probably for many more cases. So below are some imperfect ideas, may be you can shut them down and suggest something better.

Ideas

• One asymmetric force, i.e. latch with bounce and release. This works like the rubber band that is activated when scroller's tail crosses the latch while moving in the direction A, and released when an object goes far away in the opposite direction B. (btw, p2.js physics engine has a notion of breakable forces. But keep in mind that in this latch mechanism the force must be breakable only in one direction). We could, I guess, implement latch based on a collision.
• Two forces, i.e. door stop with a magnet. This works like a bouncing ball, which collides with a floor, bounces up and returns under the force of gravity, repeating the motion with small amplitude. Scroller's head bumps into the door stop object and bounces back, only to be attracted again by a magnet. I think this mechanism is more expensive as the magnetic force permeates the whole world and will need to be calculated on every step, even on distance where it does not have any effect.

Discussion with Jasper and Mark

• Jasper: I think I understand what you're going for... and I think I've got the answer for you here:
  http://jsfiddle.net/wellcaffeinated/AYPHb/1/
• Gene & Mark: Jasper, thank you! I reviewed with Mark as he will be doing the changes and looks like it will do the trick.

So, when user flicks in the opposite direction, we will break the constraint (by removing it) at the same distance (threshold) at which we added it. But we should let dev set the second distance manually.

We would also need to check not just the distance, but also a direction. As users can flick in both directions but break it only in one.

we r thinking to add things like:
c.breakOnDistance(distance1, direction /* optional /, distance2 / optional / )
for to make it flexible, also:
c.breakon(function breakTest1(body) {}) / allows dev to add his own condition checks for pos, speed, acceleration, and later for color, scale, etc. etc. */

• Jasper: Another possibility might be to define an AABB and check the position is inside that. If not break the connection.

eg:

var range = Physics.aabb( x1, y1, x2, y2 );
c.breakOutside( range );

// breakOutside implements...
if ( ! this.range.contains( this.body.state.pos ) ){
// break the constraint

Many of today's mobiles have more than one processor, and this allows to efficiently do computations without disrupting the rendering. This should reduce the amount of yellow spikes showing in the devtools timeline.

Page transitions need a slightly different model from the scroller #3 transitions.

1. they need to snap to viewport sides, even when there is more content in both directions.
2. They do not need to fly, like scroller does, with a strong flick. May be this could be achieved simply as a combination of stronger drag and stronger snap.