Extract nested and private classes from VideoCaptureBufferPool

Extract nested and private classes from VideoCaptureBufferPool

This CL is part of the Mojo Video Capture work. For the bigger picture, see [1] CL1.6.2.

This CL is a step towards being able to reuse the classes VideoCaptureDeviceClient
and VideoCaptureBufferPool as part of the Video Capture Mojo Service, because they
implement functionality that is needed there. Expressed in class-diagram form, we
want to realize the cut indicated by the red line in [2].

Currently, the classes VideoCaptureDeviceClient and VideoCaptureBufferPool live in
content/browser/renderer_host/media. Even though their functionality is not specific
to renderer_host, their dependencies create a tight coupling to code that is. In order
to use them in services/video_capture, we need to move them out of there (and probably
into media/capture/video).

In this CL we move the nested and private classes from video_capture_buffer_pool.h/cc
into stand-alone classes using separate files. After this separation, we will be able to
move the parts that do not depend on content/browser/renderer_host/media to
media/capture/video and keep the other parts where they are.

Additional changes:
* Rename interface VideoCaptureBufferPoolBufferHandle to VideoCaptureBufferHandle

Note: Code in new file comes from either video_capture_buffer_pool.h or .cc.
      No additions or modifications oder than the required includes and guards.

BUG=584797
TEST=This is a pure refactoring. No new functionality. content_unittests still pass.

[1] https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxsxWslJ_X-zpOhijvI8/edit?usp=sharing
[2] https://docs.google.com/drawings/d/1acJSbj8eCK5Lpvv9QPiU_V34t8GfgqfYSoYbA93jb5o/edit

Committed: https://crrev.com/71238feb8a373499b95a8b78572c81a456a37106
Cr-Commit-Position: refs/heads/master@{#420475}

[chfremer, 2016-09-19 21:47:11]

Description was changed from

==========
format


Fix errors from merge


Merge branch 'DeviceClientRefactor' into BufferPoolRefactor


Fixed change that was lost in merge conflict/moving code to file


Fix merge/naming issues.


Merge branch 'DeviceClientRefactor' into BufferPoolRefactor


Merge branch 'DeviceClientRefactor' into BufferPoolRefactor


Merge branch 'DeviceClientRefactor' into BufferPoolRefactor


Move nested classes out of VideoCaptureBufferPool into separate files.

BUG=
==========

to

==========
Extract nested and private classes from VideoCaptureBufferPool

This CL is part of the Mojo Video Capture work. For the bigger picture, see [1]
CL1.6.2.

This CL is a step towards being able to reuse the classes
VideoCaptureDeviceClient 
and VideoCaptureBufferPool as part of the Video Capture Mojo Service, because
they 
implement functionality that is needed there. Expressed in class-diagram form,
we 
want to realize the cut indicated by the red line in [2].

Currently, the classes VideoCaptureDeviceClient and VideoCaptureBufferPool live
in 
content/browser/renderer_host/media. Even though their functionality is not
specific 
to renderer_host, their dependencies create a tight coupling to code that is. In
order 
to use them in services/video_capture, we need to move them out of there (and
probably 
into media/capture/video).

In this CL we extract the nested and private classes from
video_capture_buffer_pool.h/cc 
into stand-alone classes using separate files. After this separation, we will be
able to 
move the parts that do not depend on content/browser/renderer_host/media to 
media/capture/video and keep the other parts where they are.

BUG=584797
TEST=This is a pure refactoring. No new functionality. content_unittests still
pass.

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
[2]
https://docs.google.com/drawings/d/1acJSbj8eCK5Lpvv9QPiU_V34t8GfgqfYSoYbA93jb...
==========

[chfremer, 2016-09-19 22:01:41]

Patchset #3 (id:40001) has been deleted

[chfremer, 2016-09-19 22:01:47]

Patchset #2 (id:20001) has been deleted

[chfremer, 2016-09-19 22:07:36]

Description was changed from

==========
Extract nested and private classes from VideoCaptureBufferPool

This CL is part of the Mojo Video Capture work. For the bigger picture, see [1]
CL1.6.2.

This CL is a step towards being able to reuse the classes
VideoCaptureDeviceClient 
and VideoCaptureBufferPool as part of the Video Capture Mojo Service, because
they 
implement functionality that is needed there. Expressed in class-diagram form,
we 
want to realize the cut indicated by the red line in [2].

Currently, the classes VideoCaptureDeviceClient and VideoCaptureBufferPool live
in 
content/browser/renderer_host/media. Even though their functionality is not
specific 
to renderer_host, their dependencies create a tight coupling to code that is. In
order 
to use them in services/video_capture, we need to move them out of there (and
probably 
into media/capture/video).

In this CL we extract the nested and private classes from
video_capture_buffer_pool.h/cc 
into stand-alone classes using separate files. After this separation, we will be
able to 
move the parts that do not depend on content/browser/renderer_host/media to 
media/capture/video and keep the other parts where they are.

BUG=584797
TEST=This is a pure refactoring. No new functionality. content_unittests still
pass.

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
[2]
https://docs.google.com/drawings/d/1acJSbj8eCK5Lpvv9QPiU_V34t8GfgqfYSoYbA93jb...
==========

to

==========
Break tight coupling of VideoCaptureDeviceClient to renderer_host

This CL is part of the Mojo Video Capture work. For the bigger picture, see [1]
CL1.6.2.

This CL is a step towards being able to reuse the classes
VideoCaptureDeviceClient 
and VideoCaptureBufferPool as part of the Video Capture Mojo Service, because
they 
implement functionality that is needed there. Expressed in class-diagram form,
we 
want to realize the cut indicated by the red line in [2].

Currently, the classes VideoCaptureDeviceClient and VideoCaptureBufferPool live
in 
content/browser/renderer_host/media. Even though their functionality is not
specific 
to renderer_host, their dependencies create a tight coupling to code that is. In
order 
to use them in services/video_capture, we need to move them out of there (and
probably 
into media/capture/video).

In this CL we move the nested and private classes from
video_capture_buffer_pool.h/cc 
into stand-alone classes using separate files. After this separation, we will be
able to 
move the parts that do not depend on content/browser/renderer_host/media to 
media/capture/video and keep the other parts where they are.

Additional changes:
* Rename interface VideoCaptureBufferPoolBufferHandle to
VideoCaptureBufferHandle

Note: Code in new file comes from either video_capture_buffer_pool.h or .cc.
      No additions or modifications oder than the required includes and guards.

BUG=584797
TEST=This is a pure refactoring. No new functionality. content_unittests still
pass.

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
[2]
https://docs.google.com/drawings/d/1acJSbj8eCK5Lpvv9QPiU_V34t8GfgqfYSoYbA93jb...
==========

[chfremer, 2016-09-19 22:07:50]

The CQ bit was checked by chfremer@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-19 22:08:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[chfremer, 2016-09-19 22:08:43]

chfremer@chromium.org changed reviewers:
+ emircan@chromium.org, mcasas@chromium.org, miu@chromium.org

[chfremer, 2016-09-19 22:08:44]

mcasas@: PTAL
miu@: PTAL
emircan@: FYI

[chfremer, 2016-09-19 22:45:43]

Description was changed from

==========
Break tight coupling of VideoCaptureDeviceClient to renderer_host

This CL is part of the Mojo Video Capture work. For the bigger picture, see [1]
CL1.6.2.

This CL is a step towards being able to reuse the classes
VideoCaptureDeviceClient 
and VideoCaptureBufferPool as part of the Video Capture Mojo Service, because
they 
implement functionality that is needed there. Expressed in class-diagram form,
we 
want to realize the cut indicated by the red line in [2].

Currently, the classes VideoCaptureDeviceClient and VideoCaptureBufferPool live
in 
content/browser/renderer_host/media. Even though their functionality is not
specific 
to renderer_host, their dependencies create a tight coupling to code that is. In
order 
to use them in services/video_capture, we need to move them out of there (and
probably 
into media/capture/video).

In this CL we move the nested and private classes from
video_capture_buffer_pool.h/cc 
into stand-alone classes using separate files. After this separation, we will be
able to 
move the parts that do not depend on content/browser/renderer_host/media to 
media/capture/video and keep the other parts where they are.

Additional changes:
* Rename interface VideoCaptureBufferPoolBufferHandle to
VideoCaptureBufferHandle

Note: Code in new file comes from either video_capture_buffer_pool.h or .cc.
      No additions or modifications oder than the required includes and guards.

BUG=584797
TEST=This is a pure refactoring. No new functionality. content_unittests still
pass.

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
[2]
https://docs.google.com/drawings/d/1acJSbj8eCK5Lpvv9QPiU_V34t8GfgqfYSoYbA93jb...
==========

to

==========
Extract nested and private classes from VideoCaptureBufferPool

This CL is part of the Mojo Video Capture work. For the bigger picture, see [1]
CL1.6.2.

This CL is a step towards being able to reuse the classes
VideoCaptureDeviceClient 
and VideoCaptureBufferPool as part of the Video Capture Mojo Service, because
they 
implement functionality that is needed there. Expressed in class-diagram form,
we 
want to realize the cut indicated by the red line in [2].

Currently, the classes VideoCaptureDeviceClient and VideoCaptureBufferPool live
in 
content/browser/renderer_host/media. Even though their functionality is not
specific 
to renderer_host, their dependencies create a tight coupling to code that is. In
order 
to use them in services/video_capture, we need to move them out of there (and
probably 
into media/capture/video).

In this CL we move the nested and private classes from
video_capture_buffer_pool.h/cc 
into stand-alone classes using separate files. After this separation, we will be
able to 
move the parts that do not depend on content/browser/renderer_host/media to 
media/capture/video and keep the other parts where they are.

Additional changes:
* Rename interface VideoCaptureBufferPoolBufferHandle to
VideoCaptureBufferHandle

Note: Code in new file comes from either video_capture_buffer_pool.h or .cc.
      No additions or modifications oder than the required includes and guards.

BUG=584797
TEST=This is a pure refactoring. No new functionality. content_unittests still
pass.

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
[2]
https://docs.google.com/drawings/d/1acJSbj8eCK5Lpvv9QPiU_V34t8GfgqfYSoYbA93jb...
==========

[mcasas, 2016-09-20 00:51:08]

lgtm with some comments/ suggestions

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/media/gpu_memory_buffer_tracker.cc (right):

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/media/gpu_memory_buffer_tracker.cc:97: case
gfx::SURFACE_TEXTURE_BUFFER:
https://codereview.chromium.org/2353453002/ is removing
this enum entry FYI (see gpu_memory_buffer.h).

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/media/shared_memory_buffer_handle.cc (right):

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/media/shared_memory_buffer_handle.cc:19: }
nit: blank line between methods, here and elsewhere.

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/media/video_capture_buffer_pool.h (right):

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/media/video_capture_buffer_pool.h:28: class
VideoCaptureBufferTracker;
Maybe also forward declare VideoCaptureBufferHandle ?

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/media/video_capture_buffer_tracker.h (right):

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/media/video_capture_buffer_tracker.h:62: //
|pixel_format_|, and |storage_type_| are set once for the lifetime of a
nit: Reflow these comments.

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/media/video_capture_buffer_tracker_factory.h
(right):

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/media/video_capture_buffer_tracker_factory.h:17:
media::VideoPixelStorage storage);
If there is just this method you can consider pegging it to 
video_capture_buffer_tracker.h, right? (It's quite verbose
to have to add 2 files).

[commit-bot: I haz the power, 2016-09-20 01:20:07]

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

[commit-bot: I haz the power, 2016-09-20 01:20:08]

Dry run: This issue passed the CQ dry run.

[chfremer, 2016-09-20 18:43:10]

mcasas@: PTAL
miu@: PTAL RS

Note: Besides addressing the comments, I added mcasas@ as owner of the extracted
code so that he keeps the ownership.

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/media/gpu_memory_buffer_tracker.cc (right):

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/media/gpu_memory_buffer_tracker.cc:97: case
gfx::SURFACE_TEXTURE_BUFFER:
On 2016/09/20 00:51:07, mcasas wrote:
> https://codereview.chromium.org/2353453002/ is removing
> this enum entry FYI (see gpu_memory_buffer.h).

Thanks for the heads up.
It seems I am unable to remove this case as long as the enum value still exists
(because the static analyzer complains otherwise).
If I want to land this before the other CL, I will ping reveman@ first.

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/media/shared_memory_buffer_handle.cc (right):

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/media/shared_memory_buffer_handle.cc:19: }
On 2016/09/20 00:51:07, mcasas wrote:
> nit: blank line between methods, here and elsewhere.

Done.

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/media/video_capture_buffer_pool.h (right):

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/media/video_capture_buffer_pool.h:28: class
VideoCaptureBufferTracker;
On 2016/09/20 00:51:08, mcasas wrote:
> Maybe also forward declare VideoCaptureBufferHandle ?

Done.

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/media/video_capture_buffer_tracker.h (right):

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/media/video_capture_buffer_tracker.h:62: //
|pixel_format_|, and |storage_type_| are set once for the lifetime of a
On 2016/09/20 00:51:08, mcasas wrote:
> nit: Reflow these comments.

Done.

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/media/video_capture_buffer_tracker_factory.h
(right):

https://codereview.chromium.org/2343423003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/media/video_capture_buffer_tracker_factory.h:17:
media::VideoPixelStorage storage);
On 2016/09/20 00:51:08, mcasas wrote:
> If there is just this method you can consider pegging it to 
> video_capture_buffer_tracker.h, right? (It's quite verbose
> to have to add 2 files).

I agree, and it actually used to be part of the Tracker interface class.

The reason I would like to separate it out here already is that in the next CL 
this static method is going to change into a pure virtual one, making 
this an actual interface. This is needed to break the dependency of
VideoCaptureBufferPool
on the concrete factory. The Video Capture Mojo service is then going to 
provide a different implementation than the existing one used by
VideoCaptureManager.

[chfremer, 2016-09-21 21:30:13]

miu@: ping PTAL RS

[chfremer, 2016-09-22 19:33:56]

chfremer@chromium.org changed reviewers:
+ avi@chromium.org

[chfremer, 2016-09-22 19:33:56]

avi@chromium.org: PTAL RS for BUILD.gn and OWNERS

[Avi (use Gerrit), 2016-09-22 19:41:05]

lgtm

stampity stamp

[chfremer, 2016-09-22 19:43:19]

The CQ bit was checked by chfremer@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-22 19:43:39]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-22 21:01:03]

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

[commit-bot: I haz the power, 2016-09-22 21:01:05]

Dry run: This issue passed the CQ dry run.

[chfremer, 2016-09-22 21:59:21]

The CQ bit was checked by chfremer@chromium.org

[chfremer, 2016-09-22 21:59:22]

The patchset sent to the CQ was uploaded after l-g-t-m from mcasas@chromium.org
Link to the patchset: https://codereview.chromium.org/2343423003/#ps100001
(title: "Merge branch 'master' into BufferPoolRefactor")

[commit-bot: I haz the power, 2016-09-22 22:00:04]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-22 22:07:02]

Description was changed from

==========
Extract nested and private classes from VideoCaptureBufferPool

This CL is part of the Mojo Video Capture work. For the bigger picture, see [1]
CL1.6.2.

This CL is a step towards being able to reuse the classes
VideoCaptureDeviceClient 
and VideoCaptureBufferPool as part of the Video Capture Mojo Service, because
they 
implement functionality that is needed there. Expressed in class-diagram form,
we 
want to realize the cut indicated by the red line in [2].

Currently, the classes VideoCaptureDeviceClient and VideoCaptureBufferPool live
in 
content/browser/renderer_host/media. Even though their functionality is not
specific 
to renderer_host, their dependencies create a tight coupling to code that is. In
order 
to use them in services/video_capture, we need to move them out of there (and
probably 
into media/capture/video).

In this CL we move the nested and private classes from
video_capture_buffer_pool.h/cc 
into stand-alone classes using separate files. After this separation, we will be
able to 
move the parts that do not depend on content/browser/renderer_host/media to 
media/capture/video and keep the other parts where they are.

Additional changes:
* Rename interface VideoCaptureBufferPoolBufferHandle to
VideoCaptureBufferHandle

Note: Code in new file comes from either video_capture_buffer_pool.h or .cc.
      No additions or modifications oder than the required includes and guards.

BUG=584797
TEST=This is a pure refactoring. No new functionality. content_unittests still
pass.

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
[2]
https://docs.google.com/drawings/d/1acJSbj8eCK5Lpvv9QPiU_V34t8GfgqfYSoYbA93jb...
==========

to

==========
Extract nested and private classes from VideoCaptureBufferPool

This CL is part of the Mojo Video Capture work. For the bigger picture, see [1]
CL1.6.2.

This CL is a step towards being able to reuse the classes
VideoCaptureDeviceClient 
and VideoCaptureBufferPool as part of the Video Capture Mojo Service, because
they 
implement functionality that is needed there. Expressed in class-diagram form,
we 
want to realize the cut indicated by the red line in [2].

Currently, the classes VideoCaptureDeviceClient and VideoCaptureBufferPool live
in 
content/browser/renderer_host/media. Even though their functionality is not
specific 
to renderer_host, their dependencies create a tight coupling to code that is. In
order 
to use them in services/video_capture, we need to move them out of there (and
probably 
into media/capture/video).

In this CL we move the nested and private classes from
video_capture_buffer_pool.h/cc 
into stand-alone classes using separate files. After this separation, we will be
able to 
move the parts that do not depend on content/browser/renderer_host/media to 
media/capture/video and keep the other parts where they are.

Additional changes:
* Rename interface VideoCaptureBufferPoolBufferHandle to
VideoCaptureBufferHandle

Note: Code in new file comes from either video_capture_buffer_pool.h or .cc.
      No additions or modifications oder than the required includes and guards.

BUG=584797
TEST=This is a pure refactoring. No new functionality. content_unittests still
pass.

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
[2]
https://docs.google.com/drawings/d/1acJSbj8eCK5Lpvv9QPiU_V34t8GfgqfYSoYbA93jb...
==========

[commit-bot: I haz the power, 2016-09-22 22:07:03]

Committed patchset #4 (id:100001)

[commit-bot: I haz the power, 2016-09-22 22:08:57]

Description was changed from

==========
Extract nested and private classes from VideoCaptureBufferPool

This CL is part of the Mojo Video Capture work. For the bigger picture, see [1]
CL1.6.2.

This CL is a step towards being able to reuse the classes
VideoCaptureDeviceClient 
and VideoCaptureBufferPool as part of the Video Capture Mojo Service, because
they 
implement functionality that is needed there. Expressed in class-diagram form,
we 
want to realize the cut indicated by the red line in [2].

Currently, the classes VideoCaptureDeviceClient and VideoCaptureBufferPool live
in 
content/browser/renderer_host/media. Even though their functionality is not
specific 
to renderer_host, their dependencies create a tight coupling to code that is. In
order 
to use them in services/video_capture, we need to move them out of there (and
probably 
into media/capture/video).

In this CL we move the nested and private classes from
video_capture_buffer_pool.h/cc 
into stand-alone classes using separate files. After this separation, we will be
able to 
move the parts that do not depend on content/browser/renderer_host/media to 
media/capture/video and keep the other parts where they are.

Additional changes:
* Rename interface VideoCaptureBufferPoolBufferHandle to
VideoCaptureBufferHandle

Note: Code in new file comes from either video_capture_buffer_pool.h or .cc.
      No additions or modifications oder than the required includes and guards.

BUG=584797
TEST=This is a pure refactoring. No new functionality. content_unittests still
pass.

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
[2]
https://docs.google.com/drawings/d/1acJSbj8eCK5Lpvv9QPiU_V34t8GfgqfYSoYbA93jb...
==========

to

==========
Extract nested and private classes from VideoCaptureBufferPool

This CL is part of the Mojo Video Capture work. For the bigger picture, see [1]
CL1.6.2.

This CL is a step towards being able to reuse the classes
VideoCaptureDeviceClient
and VideoCaptureBufferPool as part of the Video Capture Mojo Service, because
they
implement functionality that is needed there. Expressed in class-diagram form,
we
want to realize the cut indicated by the red line in [2].

Currently, the classes VideoCaptureDeviceClient and VideoCaptureBufferPool live
in
content/browser/renderer_host/media. Even though their functionality is not
specific
to renderer_host, their dependencies create a tight coupling to code that is. In
order
to use them in services/video_capture, we need to move them out of there (and
probably
into media/capture/video).

In this CL we move the nested and private classes from
video_capture_buffer_pool.h/cc
into stand-alone classes using separate files. After this separation, we will be
able to
move the parts that do not depend on content/browser/renderer_host/media to
media/capture/video and keep the other parts where they are.

Additional changes:
* Rename interface VideoCaptureBufferPoolBufferHandle to
VideoCaptureBufferHandle

Note: Code in new file comes from either video_capture_buffer_pool.h or .cc.
      No additions or modifications oder than the required includes and guards.

BUG=584797
TEST=This is a pure refactoring. No new functionality. content_unittests still
pass.

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
[2]
https://docs.google.com/drawings/d/1acJSbj8eCK5Lpvv9QPiU_V34t8GfgqfYSoYbA93jb...

Committed: https://crrev.com/71238feb8a373499b95a8b78572c81a456a37106
Cr-Commit-Position: refs/heads/master@{#420475}
==========

[commit-bot: I haz the power, 2016-09-22 22:08:59]

Patchset 4 (id:??) landed as
https://crrev.com/71238feb8a373499b95a8b78572c81a456a37106
Cr-Commit-Position: refs/heads/master@{#420475}