compositor-worker: Add CompositorProxyClient worker client of CompositorWorker.

compositor-worker: Add CompositorProxyClient worker client of CompositorWorker.

Adds the CompositorProxyClient worker to CompositorWorkers. In order to test
calling animation frame callbacks a task is created to call them when an
animation frame is requested.

BUG=430155
TEST=virtual/threaded/fast/compositorworker/request-animation-frame.html

Committed: https://crrev.com/de5eb38e0da6ac0ec80b51b77fc562334edb1c47
Cr-Commit-Position: refs/heads/master@{#396018}

[flackr, 2016-05-06 20:00:57]

flackr@chromium.org changed reviewers:
+ haraken@chromium.org, jbroman@chromium.org

[flackr, 2016-05-06 20:00:57]

Hey, this is split off from https://codereview.chromium.org/1895873006 to just
add the CompositorProxyClient worker client. I manually posted a task to fire
the CompositorProxyClient::mutate method on requestAnimationFrame so that I
could add a layout test exercising this code path. 

Please take a look, thanks.

[haraken, 2016-05-09 02:05:54]

haraken@chromium.org changed reviewers:
+ falken@chromium.org, kinuko@chromium.org

[haraken, 2016-05-09 02:05:55]

https://codereview.chromium.org/1956893003/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/compositorworker/CompositorWorker.cpp
(right):

https://codereview.chromium.org/1956893003/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/compositorworker/CompositorWorker.cpp:51:
provideCompositorProxyClientTo(workerClients,
document->frame()->chromeClient().createCompositorProxyClient());

As commented in the original CL (https://codereview.chromium.org/1895873006),
I'm not sure if this is a right way to inject the worker client. Shared workers
and dedicated workers create their worker clients via
WebWorkerContentSettingsClientProxy.

+falken +kinuko

[kinuko, 2016-05-09 02:41:27]

Worker client plumbing code looks sane to me.

https://codereview.chromium.org/1956893003/diff/1/third_party/WebKit/Source/m...
File
third_party/WebKit/Source/modules/compositorworker/CompositorWorkerGlobalScope.cpp
(right):

https://codereview.chromium.org/1956893003/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/compositorworker/CompositorWorkerGlobalScope.cpp:60:
thread()->postTask(BLINK_FROM_HERE,
createSameThreadTask(&CompositorProxyClient::triggerMutationForTest,
invoking test-only method from web-facing API and having all these code in
production code looks weird to me...

[jbroman, 2016-05-09 18:44:19]

lgtm (carried forward from the original CL)

https://codereview.chromium.org/1956893003/diff/1/third_party/WebKit/Source/m...
File
third_party/WebKit/Source/modules/compositorworker/CompositorWorkerGlobalScope.cpp
(right):

https://codereview.chromium.org/1956893003/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/compositorworker/CompositorWorkerGlobalScope.cpp:59:
// For now, just post a task to call mutate on the compositor proxy client.
Please leave a more strongly-worded TODO here so it's obvious this is a super
temporary measure. Something like:

// TODO(flackr): Remove this when ____________________.

[flackr, 2016-05-10 20:56:13]

https://codereview.chromium.org/1956893003/diff/1/third_party/WebKit/Source/m...
File
third_party/WebKit/Source/modules/compositorworker/CompositorWorkerGlobalScope.cpp
(right):

https://codereview.chromium.org/1956893003/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/compositorworker/CompositorWorkerGlobalScope.cpp:59:
// For now, just post a task to call mutate on the compositor proxy client.
On 2016/05/09 at 18:44:18, jbroman wrote:
> Please leave a more strongly-worded TODO here so it's obvious this is a super
temporary measure. Something like:
> 
> // TODO(flackr): Remove this when ____________________.

Done.

https://codereview.chromium.org/1956893003/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/compositorworker/CompositorWorkerGlobalScope.cpp:60:
thread()->postTask(BLINK_FROM_HERE,
createSameThreadTask(&CompositorProxyClient::triggerMutationForTest,
On 2016/05/09 at 02:41:26, kinuko wrote:
> invoking test-only method from web-facing API and having all these code in
production code looks weird to me...

You're right, let's just remove the ForTest and call this something more
meaningful. This is our workaround for being able to test this path when we're
not able to actually request frames from the compositor. Done.

[haraken, 2016-05-11 00:38:26]

https://codereview.chromium.org/1956893003/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/ChromeClientImpl.cpp (right):

https://codereview.chromium.org/1956893003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/ChromeClientImpl.cpp:1078: return
m_webView->createCompositorProxyClient();

Would you help me understand why you want to create the worker client via
ChromeClient?

Other WorkerClients are created in WebEmbeddedWorkerImpl::startWorkerThread.

[kinuko, 2016-05-11 02:57:49]

On 2016/05/11 00:38:26, haraken wrote:
>
https://codereview.chromium.org/1956893003/diff/20001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/web/ChromeClientImpl.cpp (right):
> 
>
https://codereview.chromium.org/1956893003/diff/20001/third_party/WebKit/Sour...
> third_party/WebKit/Source/web/ChromeClientImpl.cpp:1078: return
> m_webView->createCompositorProxyClient();
> 
> Would you help me understand why you want to create the worker client via
> ChromeClient?
> 
> Other WorkerClients are created in WebEmbeddedWorkerImpl::startWorkerThread.

WebEmbeddedWorkerImpl is ServiceWorker-only, for in-process workers the common
hook place to create new worker clients is within
createInProcessWorkerGlobalScopeProxy.  In this CL we implement this method in
Source/module code and calling into Source/web via ChromeClientImpl. 
Alternatively we could implement CompositorWorkerGlobalScopeProxyImpl in
Source/web and call necessary client creation code there.  The latter might be
cleaner while we need more plumbing classes.  Given that ChromeClient is being
used conveniently for various plumbing purpose I feel current approach could be
acceptable but I don't have strong opinion here.

[kinuko, 2016-05-11 03:25:31]

Description was changed from

==========
compositor-worker: Add CompositorProxyClient worker client of CompositorWorker.

Adds the CompositorProxyClient worker to CompositorWorkers. In order to test
calling animation frame callbacks a task is created to call them when an
animation frame is requested.

BUG=430155
TEST=virtual/threaded/fast/compositorworker/request-animation-frame.html
==========

to

==========
compositor-worker: Add CompositorProxyClient worker client of CompositorWorker.

Adds the CompositorProxyClient worker to CompositorWorkers. In order to test
calling animation frame callbacks a task is created to call them when an
animation frame is requested.

BUG=430155
TEST=virtual/threaded/fast/compositorworker/request-animation-frame.html
==========

[kinuko, 2016-05-11 03:25:31]

kinuko@chromium.org changed reviewers:
+ nhiroki@chromium.org
- falken@chromium.org

[haraken, 2016-05-11 03:32:15]

On 2016/05/11 02:57:49, kinuko wrote:
> On 2016/05/11 00:38:26, haraken wrote:
> >
>
https://codereview.chromium.org/1956893003/diff/20001/third_party/WebKit/Sour...
> > File third_party/WebKit/Source/web/ChromeClientImpl.cpp (right):
> > 
> >
>
https://codereview.chromium.org/1956893003/diff/20001/third_party/WebKit/Sour...
> > third_party/WebKit/Source/web/ChromeClientImpl.cpp:1078: return
> > m_webView->createCompositorProxyClient();
> > 
> > Would you help me understand why you want to create the worker client via
> > ChromeClient?
> > 
> > Other WorkerClients are created in WebEmbeddedWorkerImpl::startWorkerThread.
> 
> WebEmbeddedWorkerImpl is ServiceWorker-only, for in-process workers the common
> hook place to create new worker clients is within
> createInProcessWorkerGlobalScopeProxy.  In this CL we implement this method in
> Source/module code and calling into Source/web via ChromeClientImpl. 
> Alternatively we could implement CompositorWorkerGlobalScopeProxyImpl in
> Source/web and call necessary client creation code there.  The latter might be
> cleaner while we need more plumbing classes.  Given that ChromeClient is being
> used conveniently for various plumbing purpose I feel current approach could
be
> acceptable but I don't have strong opinion here.

Thanks for the background -- yeah, ChromeClient makes sense since it's a class
intended to be used to bypass the core/ => web/ dependency on the main thread.
LGTM on my side.

[flackr, 2016-05-11 16:37:43]

The CQ bit was checked by flackr@chromium.org

[flackr, 2016-05-11 16:37:44]

The patchset sent to the CQ was uploaded after l-g-t-m from jbroman@chromium.org
Link to the patchset: https://codereview.chromium.org/1956893003/#ps20001
(title: "Comment and change name of trigger method.")

[commit-bot: I haz the power, 2016-05-11 16:38:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1956893003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1956893003/20001

[commit-bot: I haz the power, 2016-05-11 17:41:52]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-11 17:41:53]

Try jobs failed on following builders:
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[flackr, 2016-05-11 23:36:41]

I forgot to pull in the TestCompositorProxyClient for
CompositorWorkerThreadTest, haraken does this still look good?

[kinuko, 2016-05-12 09:13:19]

https://codereview.chromium.org/1956893003/diff/40001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/modules/compositorworker/CompositorWorkerThreadTest.cpp
(right):

https://codereview.chromium.org/1956893003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/compositorworker/CompositorWorkerThreadTest.cpp:69:
void runAnimationFrameCallbacks() override {}
We are not testing any of these methods in this CL?

[flackr, 2016-05-12 16:09:45]

https://codereview.chromium.org/1956893003/diff/40001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/modules/compositorworker/CompositorWorkerThreadTest.cpp
(right):

https://codereview.chromium.org/1956893003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/compositorworker/CompositorWorkerThreadTest.cpp:69:
void runAnimationFrameCallbacks() override {}
On 2016/05/12 at 09:13:19, kinuko wrote:
> We are not testing any of these methods in this CL?

These methods are tested by the layout test request-animation-frame.html.
CompositorWorkerThreadTest is just testing the instantiation of the thread.

[dcheng, 2016-05-12 16:56:14]

dcheng@chromium.org changed reviewers:
+ dcheng@chromium.org

[dcheng, 2016-05-12 16:56:15]

https://codereview.chromium.org/1956893003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/ChromeClientImpl.cpp (right):

https://codereview.chromium.org/1956893003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/ChromeClientImpl.cpp:1078: return
m_webView->createCompositorProxyClient();
Why does this have to go through WebView? Why can't this just new
CompositorProxyClient directly?

[flackr, 2016-05-12 17:00:51]

https://codereview.chromium.org/1956893003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/ChromeClientImpl.cpp (right):

https://codereview.chromium.org/1956893003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/ChromeClientImpl.cpp:1078: return
m_webView->createCompositorProxyClient();
On 2016/05/12 at 16:56:15, dcheng wrote:
> Why does this have to go through WebView? Why can't this just new
CompositorProxyClient directly?

In this patch it absolutely could - I can move it there for this patch. In
https://codereview.chromium.org/1895873006 when we hook it up to the
CompositorMutatorImpl we need WebViewImpl to pass the constructed
CompositorMutatorImpl through WebLayerTreeView to the LayerTreeHostImpl.

[dcheng, 2016-05-12 17:09:29]

https://codereview.chromium.org/1956893003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/ChromeClientImpl.cpp (right):

https://codereview.chromium.org/1956893003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/ChromeClientImpl.cpp:1078: return
m_webView->createCompositorProxyClient();
On 2016/05/12 at 17:00:51, flackr wrote:
> On 2016/05/12 at 16:56:15, dcheng wrote:
> > Why does this have to go through WebView? Why can't this just new
CompositorProxyClient directly?
> 
> In this patch it absolutely could - I can move it there for this patch. In
https://codereview.chromium.org/1895873006 when we hook it up to the
CompositorMutatorImpl we need WebViewImpl to pass the constructed
CompositorMutatorImpl through WebLayerTreeView to the LayerTreeHostImpl.

I don't think that patch will work well with OOPI: the WebView won't have a
WebLayerTreeView if the main frame is a remote frame. Maybe it should be plumbed
through WebFrameWidget instead (we'll likely need to special case the main frame
case to fall back to WebViewImpl for now, since we're still in the process of
factoring out the WebWidget portions of WebView).

[flackr, 2016-05-19 22:02:29]

On 2016/05/12 at 17:09:29, dcheng wrote:
>
https://codereview.chromium.org/1956893003/diff/40001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/web/ChromeClientImpl.cpp (right):
> 
>
https://codereview.chromium.org/1956893003/diff/40001/third_party/WebKit/Sour...
> third_party/WebKit/Source/web/ChromeClientImpl.cpp:1078: return
m_webView->createCompositorProxyClient();
> On 2016/05/12 at 17:00:51, flackr wrote:
> > On 2016/05/12 at 16:56:15, dcheng wrote:
> > > Why does this have to go through WebView? Why can't this just new
CompositorProxyClient directly?
> > 
> > In this patch it absolutely could - I can move it there for this patch. In
https://codereview.chromium.org/1895873006 when we hook it up to the
CompositorMutatorImpl we need WebViewImpl to pass the constructed
CompositorMutatorImpl through WebLayerTreeView to the LayerTreeHostImpl.
> 
> I don't think that patch will work well with OOPI: the WebView won't have a
WebLayerTreeView if the main frame is a remote frame. Maybe it should be plumbed
through WebFrameWidget instead (we'll likely need to special case the main frame
case to fall back to WebViewImpl for now, since we're still in the process of
factoring out the WebWidget portions of WebView).

So ... like this? I'm a bit concerned when I actually implement the
createCompositorProxyClient method about having it (and the m_mutator member) on
both WebViewImpl and WebFrameWidgetImpl but maybe this will be fine with
appropriate helper methods.

[flackr, 2016-05-20 20:07:32]

dcheng, ping. Can you take a look?

[dcheng, 2016-05-20 23:57:47]

+kenrb as FYI

https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/ChromeClientImpl.cpp (right):

https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/ChromeClientImpl.cpp:1079: return
webFrame->frameWidget()->createCompositorProxyClient();
frameWidget() is only non-null on "local roots", so this probably needs to find
the local root first before trying to use the frame widget.

https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/WebViewImpl.cpp:113: #include
"platform/WaitableEvent.h"
There's a bunch of includes that don't look strictly necessary in this patch.

[flackr, 2016-05-25 17:47:41]

https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/ChromeClientImpl.cpp (right):

https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/ChromeClientImpl.cpp:1079: return
webFrame->frameWidget()->createCompositorProxyClient();
On 2016/05/20 at 23:57:47, dcheng wrote:
> frameWidget() is only non-null on "local roots", so this probably needs to
find the local root first before trying to use the frame widget.

Done, but can you clarify something. If the root is not local, does that mean
the current frame is not running in this process? If that's the case, we should
probably return NULL with a TODO to actually create a compositor proxy client
instance on that frame. I'm not sure how we get into this circumstance though
when this is triggered from running "new CompositorWorker" in the frame we want
to create the worker for.

https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/WebViewImpl.cpp:113: #include
"platform/WaitableEvent.h"
On 2016/05/20 at 23:57:47, dcheng wrote:
> There's a bunch of includes that don't look strictly necessary in this patch.

Thanks for noticing, these were accidentally pulled in from the patch this is
working towards.

[kenrb, 2016-05-25 18:02:16]

kenrb@chromium.org changed reviewers:
+ kenrb@chromium.org

[kenrb, 2016-05-25 18:02:17]

https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/ChromeClientImpl.cpp (right):

https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/ChromeClientImpl.cpp:1079: return
webFrame->frameWidget()->createCompositorProxyClient();
On 2016/05/25 17:47:40, flackr wrote:
> On 2016/05/20 at 23:57:47, dcheng wrote:
> > frameWidget() is only non-null on "local roots", so this probably needs to
> find the local root first before trying to use the frame widget.
> 
> Done, but can you clarify something. If the root is not local, does that mean
> the current frame is not running in this process? If that's the case, we
should
> probably return NULL with a TODO to actually create a compositor proxy client
> instance on that frame. I'm not sure how we get into this circumstance though
> when this is triggered from running "new CompositorWorker" in the frame we
want
> to create the worker for.

A 'local root' is either the top-level frame, or a local frame that has a remote
frame parent. We introduced the local root concept because if a local frame is
an OOPIF then basically it acts like a top-level frame for its descendant frames
(e.g. it has a RenderWidget and a compositor). If there are no OOPIFs on a page
then only the top-level frame has a non-null frameWidget(), but in an OOPIF
process you need to get it from the local root.

I think the code (before the most recent change) would crash if you created a
compositor worker in a local subframe?

[flackr, 2016-05-25 19:56:19]

On 2016/05/25 at 18:02:17, kenrb wrote:
>
https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/web/ChromeClientImpl.cpp (right):
> 
>
https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
> third_party/WebKit/Source/web/ChromeClientImpl.cpp:1079: return
webFrame->frameWidget()->createCompositorProxyClient();
> On 2016/05/25 17:47:40, flackr wrote:
> > On 2016/05/20 at 23:57:47, dcheng wrote:
> > > frameWidget() is only non-null on "local roots", so this probably needs to
> > find the local root first before trying to use the frame widget.
> > 
> > Done, but can you clarify something. If the root is not local, does that
mean
> > the current frame is not running in this process? If that's the case, we
should
> > probably return NULL with a TODO to actually create a compositor proxy
client
> > instance on that frame. I'm not sure how we get into this circumstance
though
> > when this is triggered from running "new CompositorWorker" in the frame we
want
> > to create the worker for.
> 
> A 'local root' is either the top-level frame, or a local frame that has a
remote frame parent. We introduced the local root concept because if a local
frame is an OOPIF then basically it acts like a top-level frame for its
descendant frames (e.g. it has a RenderWidget and a compositor). If there are no
OOPIFs on a page then only the top-level frame has a non-null frameWidget(), but
in an OOPIF process you need to get it from the local root.

Thanks for the explanation, this patch should be correct then.
> 
> I think the code (before the most recent change) would crash if you created a
compositor worker in a local subframe?

It definitely would, I just wanted to be sure that we wouldn't create a
compositor proxy client for a frame (compositor thread) running in a different
process.

[dcheng, 2016-05-25 20:09:51]

On 2016/05/25 at 19:56:19, flackr wrote:
> On 2016/05/25 at 18:02:17, kenrb wrote:
> >
https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
> > File third_party/WebKit/Source/web/ChromeClientImpl.cpp (right):
> > 
> >
https://codereview.chromium.org/1956893003/diff/60001/third_party/WebKit/Sour...
> > third_party/WebKit/Source/web/ChromeClientImpl.cpp:1079: return
webFrame->frameWidget()->createCompositorProxyClient();
> > On 2016/05/25 17:47:40, flackr wrote:
> > > On 2016/05/20 at 23:57:47, dcheng wrote:
> > > > frameWidget() is only non-null on "local roots", so this probably needs
to
> > > find the local root first before trying to use the frame widget.
> > > 
> > > Done, but can you clarify something. If the root is not local, does that
mean
> > > the current frame is not running in this process? If that's the case, we
should
> > > probably return NULL with a TODO to actually create a compositor proxy
client
> > > instance on that frame. I'm not sure how we get into this circumstance
though
> > > when this is triggered from running "new CompositorWorker" in the frame we
want
> > > to create the worker for.
> > 
> > A 'local root' is either the top-level frame, or a local frame that has a
remote frame parent. We introduced the local root concept because if a local
frame is an OOPIF then basically it acts like a top-level frame for its
descendant frames (e.g. it has a RenderWidget and a compositor). If there are no
OOPIFs on a page then only the top-level frame has a non-null frameWidget(), but
in an OOPIF process you need to get it from the local root.
> 
> Thanks for the explanation, this patch should be correct then.
> > 
> > I think the code (before the most recent change) would crash if you created
a compositor worker in a local subframe?
> 
> It definitely would, I just wanted to be sure that we wouldn't create a
compositor proxy client for a frame (compositor thread) running in a different
process.

The 'local root' concept only makes sense for a local frame. A remote frame
can't have a local root, nor can the local root of a local frame end up being
remote.

[dcheng, 2016-05-25 20:10:14]

Also, LGTM

[flackr, 2016-05-25 20:11:58]

The CQ bit was checked by flackr@chromium.org

[flackr, 2016-05-25 20:11:59]

The patchset sent to the CQ was uploaded after l-g-t-m from
haraken@chromium.org, jbroman@chromium.org
Link to the patchset: https://codereview.chromium.org/1956893003/#ps80001
(title: "Use local root frame and remove unneeded includes.")

[commit-bot: I haz the power, 2016-05-25 20:12:15]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1956893003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1956893003/80001

[commit-bot: I haz the power, 2016-05-25 20:35:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-25 20:35:47]

Try jobs failed on following builders:
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)

[flackr, 2016-05-25 21:34:37]

The CQ bit was checked by flackr@chromium.org

[commit-bot: I haz the power, 2016-05-25 21:35:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1956893003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1956893003/80001

[commit-bot: I haz the power, 2016-05-25 22:46:20]

Description was changed from

==========
compositor-worker: Add CompositorProxyClient worker client of CompositorWorker.

Adds the CompositorProxyClient worker to CompositorWorkers. In order to test
calling animation frame callbacks a task is created to call them when an
animation frame is requested.

BUG=430155
TEST=virtual/threaded/fast/compositorworker/request-animation-frame.html
==========

to

==========
compositor-worker: Add CompositorProxyClient worker client of CompositorWorker.

Adds the CompositorProxyClient worker to CompositorWorkers. In order to test
calling animation frame callbacks a task is created to call them when an
animation frame is requested.

BUG=430155
TEST=virtual/threaded/fast/compositorworker/request-animation-frame.html
==========

[commit-bot: I haz the power, 2016-05-25 22:46:22]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-05-25 22:47:53]

Description was changed from

==========
compositor-worker: Add CompositorProxyClient worker client of CompositorWorker.

Adds the CompositorProxyClient worker to CompositorWorkers. In order to test
calling animation frame callbacks a task is created to call them when an
animation frame is requested.

BUG=430155
TEST=virtual/threaded/fast/compositorworker/request-animation-frame.html
==========

to

==========
compositor-worker: Add CompositorProxyClient worker client of CompositorWorker.

Adds the CompositorProxyClient worker to CompositorWorkers. In order to test
calling animation frame callbacks a task is created to call them when an
animation frame is requested.

BUG=430155
TEST=virtual/threaded/fast/compositorworker/request-animation-frame.html

Committed: https://crrev.com/de5eb38e0da6ac0ec80b51b77fc562334edb1c47
Cr-Commit-Position: refs/heads/master@{#396018}
==========

[commit-bot: I haz the power, 2016-05-25 22:47:54]

Patchset 5 (id:??) landed as
https://crrev.com/de5eb38e0da6ac0ec80b51b77fc562334edb1c47
Cr-Commit-Position: refs/heads/master@{#396018}