lazy rendering improvement

[shaunc]

Currently, scrolling rerender is much slower than scroll. Also, startup time can sometimes be slow.

The problem with scrolling is that the rerender of components comes long after the actual scroll. The actual rerender -- copying content from declarative section (given that its available) is fairly fast. When scrolling to a long section of a very long list, there may be an added problem that the content hasn't rendered itself, but experiment with prerendering everything slowed down startup time without improving scrolling performance. So the problem really is timing of call from glimmer to rerender.

Proposed solution: two new components:

ember-lazy-buffer

Manages chunks of rendered content (here in display:none declaration block).

Two operation modes: "fast" and "slow". Fast would be used on startup -- would render chunks enough to fill screen -- but still not all at once (using Ember.run.next()), so that UI remains interactive. Fast would also be used when scrolling moves to whole other part of buffer.

Slow render would be used after minimum content is rendered -- to pre-render a buffer of content... configurable ... maybe even up to say 1K cells any amount that doesn't tax overall memory usage on typical client.

content-scroller

Hopefully a subclass of ember-collection: instead of waiting for rerender, would grab content synchronously when sliceDidChange event happens (now this is just used to tell cell buffer to pre-render more content). As low-level DOM operations are fast, this (hopefully) won't effect smoothness of scroll even if synchronous, but could be chunked if necessary for big tables. Actual (eventual) rerender of cells would become a no-op.