[Webkit-unassigned] [Bug 65734] New: Timer scheduling leads to poor framerate and responsiveness on timer-heavy pages

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=65734

           Summary: Timer scheduling leads to poor framerate and
                    responsiveness on timer-heavy pages
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jamesr at chromium.org
                CC: mjs at apple.com, darin at apple.com, fishd at chromium.org,
                    simon.fraser at apple.com, dino at apple.com,
                    dimich at chromium.org, levin at chromium.org


The current Timer scheduling logic in http://trac.webkit.org/browser/trunk/Source/WebCore/platform/ThreadTimers.cpp#L96 services all eligible pending timers for 50ms before yielding, which leads to bad behavior when a page has lots of timers running and can cap the effective framerate to <20FPS as nothing else (such as painting) can be scheduled on the main loop until the timer fires exceed the 50ms cap.

Originally this code serviced an unlimited number of timers per call to sharedTimerFired() which could lead to an indefinite hang, so a 50ms cap was added in https://bugs.webkit.org/show_bug.cgi?id=23865.  However, the only reason to yield at all after dispatching a timer is if the underlying platform implementation of setFireInterval() / sharedTimerFired() is grossly inefficient.  In chromium our implementation of this feature is optimized for frequently yielding and scheduling, so ideal behavior for us would be to fire at most one timer per call to sharedTimerFired().  Other platforms may want to choose a different behavior, but I don't think 50ms makes much sense for anyone.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.