哪些操作和事件会导致浏览器重新绘制整个视口？
我正在尝试从 google 代码存储库 实现 wmd 编辑器（例如stackoverflow 上使用的那个）我遇到了一个问题。
当您在文本区域中键入内容时，它会在浏览器中启动两个绘制操作。一种是重新绘制文本区域本身，另一种是重新绘制预览面板。您可以通过打开 chrome 检查器并使用时间线选项卡，同时在问题字段中输入一些文本，在 stackoverflow 上观看这一情况的发生。
但在我的页面上，浏览器在必须执行这些绘制操作时会重新绘制整个视口。这需要更长的时间......我的页面上的每个绘制操作大约需要 100 毫秒，而 stackoverflow 上大约需要 1 毫秒。
在我的测试中，这似乎与 css 相关...我可以通过剥离所有样式在 wmd-new 示例页面中重新创建此行为。
我的页面尚未公开，但希望我能以通用的方式询问...什么会导致浏览器在 dom 更改时重新绘制整个视口，而不是仅仅重新绘制 dom 的该部分？
我在这里谈论的内容的一个观点。 
I'm trying to implement the wmd-editor from the google code repository (like the one used on stackoverflow right here) and I'm running into an issue.
As you type into the textarea, it kicks off two paint operations in the browser. One to repaint the textarea itself, and one to repaint the preview panel. You can watch this happening on stackoverflow by opening the chrome inspector and using the timeline tab while typing some text into a question field.
But on my page, the browser repaints the entire viewport when it has to do these paint operations. And that takes much longer... about 100ms for each paint operation on my page versus about 1ms on stackoverflow.
In my testing this seems to be css related... I can recreate this behavior in the wmd-new example page by stripping all styles.
My page isn't public yet, but hopefully I can ask in a generic way... what will cause the browser to repaint the entire viewport on a dom change instead of just repainting that portion of the dom?
A view of what I'm talking about here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
啊哈！啊-真TM-哈！ （原谅我的热情）
问题是我使用 box-shadow css 属性来构建我的页面。当浏览器需要计算每次更改的阴影时，重排/重绘内容需要更长的时间（约 100 毫秒 vs 约 1 毫秒）。当使用 wmd-editor 时，您会在每次按键时更新 dom，因此差异会增加。当浏览器最大化时，效果最为夸张，因为它会重新计算整个视口。
所以也许这就是 stackoverflow 页面上没有任何框架或阴影的原因之一......只有干净的边缘。
您可以在这个示例页面中明白我的意思。在 Firefox 中打开它，最大化页面，然后开始打字。现在使用 firebug 删除 body 元素上的 box-shadow 属性，关闭 firebug 并重试。差别很大。
感谢 Balpha 的评论，这是正确的。
AHA! Ah-effing-ha! (forgive the enthusiasm)
The issue is that I was using the box-shadow css property to frame my page. It takes longer to reflow/repaint content when the browser needs to calculate that shadow on each change (~100ms vs ~1ms). And when using wmd-editor, you're updating the dom on each keypress, so that difference adds up. And the effect is most exaggerated when the browser is maximized, as it recalculates the entire viewport.
So maybe that's one of the reasons stackoverflow doesn't have any frames or shadows on the page... just clean edges.
You can see what I mean at this example page. Open it up in firefox, maximized the page, and start typing away. Now use firebug to remove the box-shadow property on the body element, close firebug back up and try again. Big difference.
Thanks to Balpha for his comment, which was spot on.
请查看此演示文稿的第 70 张幻灯片和接下来的幻灯片。他们解释了一些可能导致回流和重绘的原因。
http://www.slideshare.net/nzakas/high-performance -javascript-webdirections-usa-2010
如果没有特定的代码/CSS，很难回答，但我可以说一些一般性的话，比如，如果更改的片段 DOM 影响页面中的其他元素:)
另请注意，在 stackoverflow 中WMD，当您输入换行符时，它也会导致整个视口重新绘制。那么也许这与您的所见即所得区域没有明确定义宽度和高度有关？我猜如果你给它们宽度和高度，它们不会影响页面中的其他元素
Check this presentation, around slide 70 and the next ones. They explain a bit what can cause reflow and repaint.
http://www.slideshare.net/nzakas/high-performance-javascript-webdirections-usa-2010
Without the specific code / CSS is hard to answer but I can say something general like, if the fragment DOM that was changed influences other elements in the page :)
Also note that in stackoverflow WMD, when you enter a newline it also causes a whole viewport repaint. So maybe it has something to do with your WYSIWYG area not having width and height well defined? I'm guessing that if you give them width and height they won't affect other elements in the page