Bug 85690 - [chromium] Should not use a timer to tick backgrounded animations in single thread mode
Summary: [chromium] Should not use a timer to tick backgrounded animations in single t...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: vollick
URL:
Keywords:
Depends on: 84620
Blocks: 85813
  Show dependency treegraph
 
Reported: 2012-05-04 19:27 PDT by vollick
Modified: 2012-05-21 15:20 PDT (History)
4 users (show)

See Also:


Attachments
Patch (17.00 KB, patch)
2012-05-04 19:33 PDT, vollick
no flags Details | Formatted Diff | Diff
Patch (17.70 KB, patch)
2012-05-08 11:09 PDT, vollick
no flags Details | Formatted Diff | Diff
Patch (17.74 KB, patch)
2012-05-08 13:31 PDT, vollick
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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).