We can reduce time spent invalidating system painting surface by deferring repaints in Document::recalcStyle(). We already do this for layouts.
<rdar://problem/9192489>
Created attachment 88312 [details] patch
Comment on attachment 88312 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=88312&action=review > Source/WebCore/dom/Document.cpp:1566 > - if (view()) > - view()->resumeScheduledEvents(); > + if (frameView) { Is there any change that view() could become 0 during the process of style recalculation?
Comment on attachment 88312 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=88312&action=review >> Source/WebCore/dom/Document.cpp:1566 >> + if (frameView) { > > Is there any change that view() could become 0 during the process of style recalculation? chance, not change > Source/WebCore/dom/Document.cpp:1568 > + frameView->endDeferredRepaints(); Is there any chance that repaints were already deferred and we are ending the deferral too soon?
(In reply to comment #4) > > Is there any change that view() could become 0 during the process of style recalculation? That would probably indicate bug elsewhere Nevertheless, I switched to a protected pointer: RefPtr<FrameView> frameView = view(); > > Source/WebCore/dom/Document.cpp:1568 > > + frameView->endDeferredRepaints(); > > Is there any chance that repaints were already deferred and we are ending the deferral too soon? begin/endDeferredRepaints are counting.
http://trac.webkit.org/changeset/82992