WebGraphicsContext3DCommandBufferImpl cleanup, Canvas2D thottling fix, GpuScheduler fix.

WebGraphicsContext3DCommandBufferImpl cleanup:
- Removed unused methods deleteCompositorTexture and createCompositorTexture.
- Removed redundant method copyTextureToCompositor.

Canvas2D thottling fix:
- Removed throttling, because it assumed only one canvas, but there are N canvases calling CopyTextureToParentTexture.
- Flush isn't necessary, because the caller was already flushing (DrawingBufferChromium.cpp).
- We will need a followup bug fix in WebKit that will throttle setInterval/setTimeout dirtying of SharedGraphicsContext. Similar to how WebGL is throttled. (http://code.google.com/p/chromium/issues/detail?id=84781)

GpuScheduler fix:
- Ganesh generates a lot of cheap GL commands, so 100 commands were executing in 50us, causing us to spin on PostTask(ProcessCommands) 60+ times per frame. This change simply tracks the elapsed time after each 100 commands - if the time is less than 2ms, it continues on to the next 100 commands.

(These are independent changes - could be split up if necessary.)

BUG=83628
TEST=trace FishIE demo with 500 fish, check that ProcessCommands is not called ~60 times per frame.

[jbates, 2011-06-02 22:02:49]

Three changes here, if it's too much I can split them up.

[apatrick_chromium, 2011-06-02 22:07:43]

http://codereview.chromium.org/7058035/diff/1/gpu/command_buffer/service/gpu_...
File gpu/command_buffer/service/gpu_scheduler.cc (right):

http://codereview.chromium.org/7058035/diff/1/gpu/command_buffer/service/gpu_...
gpu/command_buffer/service/gpu_scheduler.cc:183: base::TimeTicks start_time =
base::TimeTicks::Now();
Does this have sufficient precision to measure 2ms on all platforms?

http://codereview.chromium.org/7058035/diff/1/gpu/command_buffer/service/gpu_...
gpu/command_buffer/service/gpu_scheduler.cc:219: elapsed.InMicroseconds() <
2000);
Could be a constant.

[piman, 2011-06-02 22:41:02]

LGTM with Al's observations.

[jbates, 2011-06-03 00:05:55]

The latest CL also updates a gpu_scheduler test to trigger a break from
ProcessCommands loop via a thread sleep.

http://codereview.chromium.org/7058035/diff/1/gpu/command_buffer/service/gpu_...
File gpu/command_buffer/service/gpu_scheduler.cc (right):

http://codereview.chromium.org/7058035/diff/1/gpu/command_buffer/service/gpu_...
gpu/command_buffer/service/gpu_scheduler.cc:183: base::TimeTicks start_time =
base::TimeTicks::Now();
On 2011/06/02 22:07:43, apatrick_chromium wrote:
> Does this have sufficient precision to measure 2ms on all platforms?

Not guaranteed according to the TimeTicks::Now() documentation, but even in the
worst case where some platform has 15ms resolution, we have latches and other
yielding means to make sure we switch contexts when necessary.

Any worse than 1ms granularity should be rare though, since we haven't seen
anything like that in our development environment.

http://codereview.chromium.org/7058035/diff/1/gpu/command_buffer/service/gpu_...
gpu/command_buffer/service/gpu_scheduler.cc:219: elapsed.InMicroseconds() <
2000);
On 2011/06/02 22:07:43, apatrick_chromium wrote:
> Could be a constant.

Done.

[apatrick_chromium, 2011-06-03 18:58:52]

http://codereview.chromium.org/7058035/diff/1007/gpu/command_buffer/service/m...
File gpu/command_buffer/service/mocks.cc (right):

http://codereview.chromium.org/7058035/diff/1007/gpu/command_buffer/service/m...
gpu/command_buffer/service/mocks.cc:28:
SpecializedAsyncAPIMock::SpecializedAsyncAPIMock() {}
The name does not describe what the specialized mock does. How about
SlowAsyncAPIMock or something?

http://codereview.chromium.org/7058035/diff/1007/gpu/command_buffer/service/m...
gpu/command_buffer/service/mocks.cc:37: base::PlatformThread::Sleep(3);
I fear this is going to make the test flaky if the timer precision is not
sufficient. How about a loop that calls base::TimeTicks::Now to verify that the
required amount of time has elapsed and sleep again if it has not.

[jamesr, 2011-06-03 19:09:32]

My preference is always to break patches like this up, especially since we'll
want to merge at least part of this to m13 (assuming accelerated canvas2d stays
enabled).  The individual pieces can get reviewed+landed faster and the merges
will be easier if the patches are smaller.

http://codereview.chromium.org/7058035/diff/1007/gpu/command_buffer/service/g...
File gpu/command_buffer/service/gpu_scheduler_unittest.cc (right):

http://codereview.chromium.org/7058035/diff/1007/gpu/command_buffer/service/g...
gpu/command_buffer/service/gpu_scheduler_unittest.cc:47: async_api_.reset(new
StrictMock<SpecializedAsyncAPIMock>);
what's so special about this mock?  in what way is it more specialized than any
other mock?

[jbates, 2011-06-03 21:27:32]

This issue has been split into the following three:
http://codereview.chromium.org/7024027/
http://codereview.chromium.org/7024028/
http://codereview.chromium.org/6993032

I'm not sure the Canvas throttling removal change is ready for M13 without
webkit-side throttling implemented. It needs testing regarding DOS issues, etc.

http://codereview.chromium.org/7058035/diff/1007/gpu/command_buffer/service/g...
File gpu/command_buffer/service/gpu_scheduler_unittest.cc (right):

http://codereview.chromium.org/7058035/diff/1007/gpu/command_buffer/service/g...
gpu/command_buffer/service/gpu_scheduler_unittest.cc:47: async_api_.reset(new
StrictMock<SpecializedAsyncAPIMock>);
On 2011/06/03 19:09:32, jamesr wrote:
> what's so special about this mock?  in what way is it more specialized than
any
> other mock?

Isn't that similar to asking in what way is the AsyncAPI class Async? You have
to look at its definition to find out in both cases :P It is a specialized
subclass of the mock: it overrides the method that the mock provides and
specializes it. Anyway, I made the class name longer since this tripped up both
reviewers.

http://codereview.chromium.org/7058035/diff/1007/gpu/command_buffer/service/m...
File gpu/command_buffer/service/mocks.cc (right):

http://codereview.chromium.org/7058035/diff/1007/gpu/command_buffer/service/m...
gpu/command_buffer/service/mocks.cc:28:
SpecializedAsyncAPIMock::SpecializedAsyncAPIMock() {}
On 2011/06/03 18:58:52, apatrick_chromium wrote:
> The name does not describe what the specialized mock does. How about
> SlowAsyncAPIMock or something?

Done. But not Slow, because it is still a generic class used for all tests. It's
just that it has specialized the DoCommand method for specific command behavior.

http://codereview.chromium.org/7058035/diff/1007/gpu/command_buffer/service/m...
gpu/command_buffer/service/mocks.cc:37: base::PlatformThread::Sleep(3);
On 2011/06/03 18:58:52, apatrick_chromium wrote:
> I fear this is going to make the test flaky if the timer precision is not
> sufficient. How about a loop that calls base::TimeTicks::Now to verify that
the
> required amount of time has elapsed and sleep again if it has not.

Done.