Bug 95480

Summary: Repaints should not be deferred after initial page load is complete
Product: WebKit Reporter: Antti Koivisto <koivisto>
Component: Page LoadingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, ddkilzer, japhet, simon.fraser, thorton, webkit.review.bot, zalan
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
patch simon.fraser: review+

Antti Koivisto
Reported 2012-08-30 10:52:21 PDT
Any dynamically triggered resource loading currently sends us back to deferred paint mode, making animation choppy. This is not the intention of this code.
Attachments
patch (8.94 KB, patch)
2012-08-31 10:25 PDT, Antti Koivisto 		simon.fraser: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Antti Koivisto
Comment 1 2012-08-30 10:54:42 PDT
<rdar://problem/12163073>
Antti Koivisto
Comment 2 2012-08-31 10:25:55 PDT
Created attachment 161727 [details] patch
Simon Fraser (smfr)
Comment 3 2012-08-31 10:41:30 PDT
Comment on attachment 161727 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=161727&action=review > Source/WebCore/ChangeLog:21 > + (WebCore): You can remove this line. > Source/WebCore/loader/FrameLoader.cpp:758 > + m_frame->view()->checkStopDelayingDeferredRepaints(); I have a hard time parsing this function name. Maybe we can rename it? > Source/WebCore/page/FrameView.cpp:104 > +double FrameView::s_normalDeferredRepaintDelay = 0.025; Should we make this 16ms to avoid crapping on animations? > Source/WebCore/page/FrameView.cpp:2059 > + double increamentedRepaintDelay = m_deferredRepaintDelay + s_deferredRepaintDelayIncrementDuringLoading; increamentedRepaintDelay -> incrementedRepaintDelay
Antti Koivisto
Comment 4 2012-09-02 03:34:10 PDT
http://trac.webkit.org/changeset/127388
Note You need to log in before you can comment on or make changes to this bug.