Bug 57886 – Defer repaints during style recalc

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Antti Koivisto]

We can reduce time spent invalidating system painting surface by deferring repaints in Document::recalcStyle(). We already do this for layouts.

[Antti Koivisto]

<rdar://problem/9192489>

[Antti Koivisto]

Created attachment 88312 [details]
patch

[Darin Adler]

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?

[Darin Adler]

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?

[Antti Koivisto]

(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.

[Antti Koivisto]

http://trac.webkit.org/changeset/82992