Alternative mutator system which uses requestAnimationFrame to reduce drawchurn

[issa-tseng]

The primary complexity in implementing this is that rendering would no longer be synchronous. This is actually probably a great thing, because node.js does not like it if you spend too long in synchronous space, as can happen if one attempts to render too much at once.

However, if we do this it becomes much, much harder to automatically understand when rendering is complete, eg for Manifest results. Because Janus is heavily decoupled, there is no central state we can access or register against, and anyway such an approach would probably be extremely expensive anyway.

The likely alternative is something like this:

1. If requestAnimationFrame does not exist, render synchronously.
2. If it does exist, use it to render asynchronously.
3. Have some clever way to make the branch between 1 and 2 nonpainful.
4. Optionally in the server environment, have a prepackaged requestAnimationFrame that Manifest understands, so it can manually fire the thing and make the async case actually work.

[issa-tseng]

I gave this a try, including a solution wherein we don't have to be synchronous if rAF does not exist; we can have Manifest manually manage the render cycles.

The main problem seems to be with the fact that now view rendering does not occur immediately, which becomes a problem when writing synchronous interaction events (eg generate a new entry at the end of a list, and then grab the view in order to call something on it).

Barring some solution to make such tasks saner (in particular, eliminating the use of .data('view') in favor of .. something else), this change introduces a lot of userland complexity.

[issa-tseng]

In addition, a global management system is required which is able to toggle modes, because if a lot of nested views exist then even rendering them at 60fps is too slow and obvious; we have to defer a frame to start the rendertree, but we'd want to complete that rendertree synchronously.

[issa-tseng]

Okay, so:

1. now that the View Navigator system exists, the first concern around .data('view') is somewhat reduced, though the unreliability of view render timing is still probably annoying to work with in practice.
2. looking again at the code, it's likely that much like with .attach(), the nested viewtree problem is solved by computing the entire viewtree but cordoning only the dom manip operations in the queue command?