javascript - 重新计算样式 : why so stuttering?

Question

假设我们有一段代码可以将一系列相似的元素注入(inject)到 DOM 中。像这样:

var COUNT = 10000,
    elements = Object.keys(Array(COUNT).join('|').split('|'));

var d = document, 
    root = d.getElementById('root');

function inject() {
    var count = COUNT,
        ul     = d.createElement('ul'),
        liTmpl = d.createElement('li'),
        liEl   = null;

    console.time('Processing elements');
    while (count--) {
        liEl = liTmpl.cloneNode(false);
        liEl.textContent = elements[count];
        ul.appendChild(liEl);
    }
    console.timeEnd('Processing elements');

    console.time('Appending into DOM');
    root.appendChild(ul);
    console.timeEnd('Appending into DOM');
};
d.getElementById('inject').addEventListener('click', inject);

Demo .

当此片段在 Firefox (25.0) 中运行时，调用“注入(inject)”和实际看到其结果之间的时间或多或少对应于 time/timeEnd 记录的内容。对于 1000 个元素，大约 4 毫秒； 10000，大约 40 等等。很正常，不是吗？

然而，对于 Chrome(已测试 30.0 和 Canary 32.0)，情况并非如此。虽然报告的处理和附加时间实际上比 Firefox 少，但这些元素的呈现要多得多。

困惑的是，我针对不同的场景检查了 Chrome 的分析器 - 结果发现瓶颈在重新计算样式操作中。 10000个节点需要2-3秒，20000个节点需要8秒，30000个节点需要17秒。

---

现在真正的问题是:有没有人遇到过同样的情况，是否有任何解决方法？

我们考虑过的一种可能的方法是在一种延迟加载中限制这些节点的可见性('一种'，因为它更多地是关于'延迟显示':元素已经就位，只有它们的 visibility 将受到限制)。确认仅当元素即将变为可见时才会触发“重新计算样式”(这实际上是有道理的)。

Answer 1

看起来问题出在具有 display:list-item

的 li 元素上

如果你使用 div 元素而不是 ul/li 元素，它在 chrome 中运行得非常快..

同时创建 li{display:block;} 的 css 规则修复了延迟。

并且手动添加 list-item 会显示延迟，即使元素已经在 DOM 中呈现(当然必须重新呈现)

参见 http://jsfiddle.net/6D7sM/1/ 的演示

(看来 chrome 在渲染 display:list-item 元素时很慢)

---

还有一个相关bug提交给chrome http://code.google.com/p/chromium/issues/detail?id=71305已合并到 http://code.google.com/p/chromium/issues/detail?id=%2094248 (看起来在早期版本中它是崩溃的 chrome，但它已被修复。崩溃，而不是速度)