Simplify rate limiting since it's main thread shared context only

Simplify rate limiting since it's main thread shared context only

This simplifies the compositor rate limiting code to only rate limit the
shared main thread context, which as it happens is the only context that uses
this feature at all.

BUG=181120
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=232972

[jamesr, 2013-11-02 00:21:20]

The only thing that uses the rate limiting 'feature' is Canvas2DLayerBridge:

https://code.google.com/p/chromium/codesearch#search/&q=setRateLimitContext&s...

which always uses the shared main thread context. This takes advantage of that
fact in the rate limiting logic by not going through the cc::TextureLayerClient
to get at a context pointer.  Instead, it just asks the embedder to limit. 
Since only one cc::LayerTreeHostClient type has to deal with this rate limiting
logic and doing nothing is a perfectly valid rate limiting strategy, i left a
default empty impl in cc::LayerTreeHostClient.

[jamesr, 2013-11-02 00:31:32]

https://codereview.chromium.org/53153006/diff/1/cc/trees/layer_tree_host_clie...
File cc/trees/layer_tree_host_client.h (right):

https://codereview.chromium.org/53153006/diff/1/cc/trees/layer_tree_host_clie...
cc/trees/layer_tree_host_client.h:47: // Blah blah blah bullshit
Hmm, guess I have to improve this comment a bit before landing. It's fairly
accurate as is, however.

[piman, 2013-11-02 01:07:37]

lgtm

https://codereview.chromium.org/53153006/diff/1/cc/trees/layer_tree_host_clie...
File cc/trees/layer_tree_host_client.h (right):

https://codereview.chromium.org/53153006/diff/1/cc/trees/layer_tree_host_clie...
cc/trees/layer_tree_host_client.h:47: // Blah blah blah bullshit
On 2013/11/02 00:31:32, jamesr wrote:
> Hmm, guess I have to improve this comment a bit before landing. It's fairly
> accurate as is, however.

Lol.

[Stephen White, 2013-11-03 02:01:24]

This seems reasonable. I'm surprised that WebGL isn't doing rate limiting
anymore, since swamping it with rendering commands was a problem at one point as
well. Ken, is WebGL using a different mechanism now?

[Justin Novosad, 2013-11-04 16:12:36]

Looks reasonable to me, but I wonder how CanvaProxy/WorkerCanvas/whatever is
going to interact with this.  Since the spec is still in flux, I think it is
pointless to design for it now, but we need to keep in mind that we will
probably eventually need to do some rate limiting in web workers.

[Ken Russell (switch to Gerrit), 2013-11-04 18:26:06]

On 2013/11/03 02:01:24, Stephen White wrote:
> This seems reasonable. I'm surprised that WebGL isn't doing rate limiting
> anymore, since swamping it with rendering commands was a problem at one point
as
> well. Ken, is WebGL using a different mechanism now?

I looked through the code and it looks like WebGL was not calling
WebExternalTextureLayer::setRateLimitContext. Apps using requestAnimationFrame
would automatically be throttled; I don't know what would happen for those
incorrectly using setTimeout(0).

[commit-bot: I haz the power, 2013-11-04 20:29:08]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jamesr@chromium.org/53153006/150001

[commit-bot: I haz the power, 2013-11-05 00:42:25]

Retried try job too often on linux_rel for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_rel&...

[commit-bot: I haz the power, 2013-11-05 01:23:19]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jamesr@chromium.org/53153006/150001

[commit-bot: I haz the power, 2013-11-05 03:09:21]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jamesr@chromium.org/53153006/150001

[commit-bot: I haz the power, 2013-11-05 05:32:25]

Retried try job too often on win_rel for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-11-05 06:21:14]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jamesr@chromium.org/53153006/150001

[commit-bot: I haz the power, 2013-11-05 14:05:57]

Change committed as 232972