Bug 85690

Summary: [chromium] Should not use a timer to tick backgrounded animations in single thread mode
Product: WebKit Reporter: vollick
Component: WebKit Misc.Assignee: vollick
Status: RESOLVED WONTFIX    
Severity: Normal CC: cc-bugs, jamesr, nduca, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 84620    
Bug Blocks: 85813    
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

vollick
Reported 2012-05-04 19:27:13 PDT
Currently, the CCLayerTreeHostImpl starts a timer to tick animations on backgrounded tabs. This causes a number of problems. First, it causes an assert in single threaded mode because it ticks on the main thread, not the impl thread. Second, we should never be using a timer in single threaded mode because with https://bugs.webkit.org/show_bug.cgi?id=84620, composites are scheduled externally (and the CCSingleThreadProxy explicitly schedules them when required). Since the timer is only used with the threaded compositor, a better home for it would be the CCThreadProxy. CCLTHI can then enable/disable the timer via its client's interface.
Attachments
Patch (17.00 KB, patch)
2012-05-04 19:33 PDT, vollick
no flags
Patch (17.70 KB, patch)
2012-05-08 11:09 PDT, vollick
no flags
Patch (17.74 KB, patch)
2012-05-08 13:31 PDT, vollick
no flags
vollick
Comment 1 2012-05-04 19:33:28 PDT
Dana Jansens
Comment 2 2012-05-04 21:26:21 PDT
Comment on attachment 140373 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=140373&action=review > Source/WebCore/ChangeLog:7 > + Throw that bug comment in here? :)
James Robinson
Comment 3 2012-05-07 12:57:45 PDT
Since we never composite while not visible, what ensures that "hardware" animations still advance and fire WebCore notifications in background tabs? Or do we not need to do that?
vollick
Comment 4 2012-05-08 11:09:26 PDT
Created attachment 140746 [details] Patch (In reply to comment #3) > Since we never composite while not visible, what ensures that "hardware" animations still advance and fire WebCore notifications in background tabs? Or do we not need to do that? With https://bugs.webkit.org/show_bug.cgi?id=84620, when the CCSingleThreadProxy is asked to commit, it will notice when the composite it schedules won't actually result in a composite (because we're hidden), and manually schedule one if there's an animation. This will not result in any drawing while hidden, though -- the code will bail early if we're not visible. This will advance the hardware animations.
James Robinson
Comment 5 2012-05-08 12:58:02 PDT
Looks like you have merge conflicts in CCThreadProxy, mind refreshing so EWS runs?
vollick
Comment 6 2012-05-08 13:29:35 PDT
(In reply to comment #5) > Looks like you have merge conflicts in CCThreadProxy, mind refreshing so EWS runs?
vollick
Comment 7 2012-05-08 13:31:11 PDT
Created attachment 140769 [details] Patch (In reply to comment #5) > Looks like you have merge conflicts in CCThreadProxy, mind refreshing so EWS runs? Done
Eric Seidel (no email)
Comment 8 2012-05-21 15:20:41 PDT
Comment on attachment 140769 [details] Patch Cleared review? from attachment 140769 [details] so that this bug does not appear in http://webkit.org/pending-review. If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).
Note You need to log in before you can comment on or make changes to this bug.