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

Description vollick 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.
Comment 1 vollick 2012-05-04 19:33:28 PDT
Created attachment 140373 [details]
Patch
Comment 2 Dana Jansens 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? :)
Comment 3 James Robinson 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?
Comment 4 vollick 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.
Comment 5 James Robinson 2012-05-08 12:58:02 PDT
Looks like you have merge conflicts in CCThreadProxy, mind refreshing so EWS runs?
Comment 6 vollick 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?
Comment 7 vollick 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
Comment 8 Eric Seidel (no email) 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).