we have many dom-repeats, and we're converting some iron-lists to dom-repeats because they're too finicky ( issue 600812 )

by default, dom-repeat renders all items immediately, which may be expensive in aggregate. we can enable chunking by setting initialCount: https://www.polymer-project.org/1.0/docs/api/dom-repeat#property-initialCount

this causes only <initialCount> template instances to be created at a time, and an additional <initialCount> come into being at every asynchronous interval. that alone means we can paint earlier, at the cost of having items pop into existence after first paint.

setting targetFramerate adjusts the interval at which each set of <initialCount> items are created: https://www.polymer-project.org/1.0/docs/api/dom-repeat#property-targetFramerate

1. is the flicker/stuttering induced by chucking as more and more items pop into existence noticeable? if not, perhaps we should just use initialCount everywhere. otherwise, we could perhaps work around it by:
  A. only using this for sub-pages that need to be rendered (for Search) but aren't actually visible;
  B. checking the height of the 1st item and preemptively setting the height of the whole container to items.length * itemHeight;
  C. having some global boolean "hurryUpAndRenderDammit" which we use to compute the value of initialCount for all dom-repeats: either infinity (in the case of your average sub-page where it's the only thing loading and we aren't under extreme time pressure) or 1 (in the case of initial load or force-rendering for Search)

I'd like to use this bug to track ideas, investigation, results and/or work for this concept. It's not necessarily settings-specific but other UIs tend to use dom-repeats either not at all, or for their main content that needs to actually be populated.