VideoCapture: more migration IPC-->mojo, part 5

VideoCapture: more migration IPC-->mojo, part 5

This CL migrates the video capture messages
VideoCaptureMsg_BufferReady and FreeBuffer
to mojom.

This step of the migration was quite straightforward,
most of the +- lines come from unittest adjustments,
and also I threw away some unused code in
video_capture_host_unittest.cc.

BUG=651897
Committed: https://crrev.com/2ff39f629a774ee513cc69d831d78908a6953e9d
Cr-Commit-Position: refs/heads/master@{#424520}

[mcasas, 2016-10-11 03:41:27]

Patchset #1 (id:1) has been deleted

[mcasas, 2016-10-11 03:41:32]

Patchset #1 (id:20001) has been deleted

[mcasas, 2016-10-11 03:41:40]

Patchset #1 (id:40001) has been deleted

[mcasas, 2016-10-11 03:46:08]

Description was changed from

==========
VideoCapture: more migration IPC-->mojo, part 5

wip

BUG=651897
==========

to

==========
VideoCapture: more migration IPC-->mojo, part 5

This CL migrates the video capture messages
VideoCaptureMsg_BufferReady and FreeBuffer
to mojom. 

This step of the migration was quite straightforward,
most of the +- lines come from unittest adjustments,
and also I threw away some unused code in 
video_capture_host_unittest.cc.

BUG=651897
==========

[mcasas, 2016-10-11 04:18:30]

Patchset #1 (id:60001) has been deleted

[mcasas, 2016-10-11 04:47:29]

Patchset #1 (id:80001) has been deleted

[mcasas, 2016-10-11 05:22:56]

mcasas@chromium.org changed reviewers:
+ chfremer@chromium.org, tsepez@chromium.org

[mcasas, 2016-10-11 05:22:57]

chfremer@ PTAL

tsepez@ mojo/messages RS plz

(only two CLs remaining!!! including this one)

[Tom Sepez, 2016-10-11 16:04:14]

messages/mojom LGTM

[chfremer, 2016-10-11 16:59:38]

lgtm % comment

https://codereview.chromium.org/2409893003/diff/100001/content/common/video_c...
File content/common/video_capture.mojom (right):

https://codereview.chromium.org/2409893003/diff/100001/content/common/video_c...
content/common/video_capture.mojom:27: };
For some of our Mojo struct, we now already have type mapping to equivalent C++
structs in place. I am wondering if we should try to consistently always provide
equivalent C++ structs and type mapping, or if it is okay to sometimes do it and
sometimes use the Mojo types directly. If we want to go for consistency, we
should add the type mapping immediately when we introduce a new Mojo struct.

[mcasas, 2016-10-11 17:35:58]

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

[mcasas, 2016-10-11 17:35:59]

avi@ plz RS two interface additions to content/common/BUILD.gn

[mcasas, 2016-10-11 17:39:37]

https://codereview.chromium.org/2409893003/diff/100001/content/common/video_c...
File content/common/video_capture.mojom (right):

https://codereview.chromium.org/2409893003/diff/100001/content/common/video_c...
content/common/video_capture.mojom:27: };
On 2016/10/11 16:59:38, chfremer wrote:
> For some of our Mojo struct, we now already have type mapping to equivalent
C++
> structs in place. I am wondering if we should try to consistently always
provide
> equivalent C++ structs and type mapping, or if it is okay to sometimes do it
and
> sometimes use the Mojo types directly. If we want to go for consistency, we
> should add the type mapping immediately when we introduce a new Mojo struct. 

I was discussing something similar yesterday, and
my understanding is that:
- if there is a C++ struct:
-- it's OK to use [Native] and use C++-in-mojo
-- it's even better to have a mojo type + typemappings
- but if there isn't a C++ equivalent, I would go
ahead and use mojom everywhere, which is what
I'm kind of doing here.
In this particular case, VideoFrameInfo is only
used in this particular interface, so it doesn't
matter much.

[mcasas, 2016-10-11 17:39:45]

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

[commit-bot: I haz the power, 2016-10-11 17:40:05]

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-10-11 17:42:50]

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

[commit-bot: I haz the power, 2016-10-11 17:42:51]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[mcasas, 2016-10-11 17:57:06]

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

[commit-bot: I haz the power, 2016-10-11 17:57:18]

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-10-11 19:32:42]

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

[commit-bot: I haz the power, 2016-10-11 19:32:43]

Dry run: This issue passed the CQ dry run.

[Avi (use Gerrit), 2016-10-11 19:40:28]

On 2016/10/11 17:39:37, mcasas wrote:
>
https://codereview.chromium.org/2409893003/diff/100001/content/common/video_c...
> File content/common/video_capture.mojom (right):
> 
>
https://codereview.chromium.org/2409893003/diff/100001/content/common/video_c...
> content/common/video_capture.mojom:27: };
> On 2016/10/11 16:59:38, chfremer wrote:
> > For some of our Mojo struct, we now already have type mapping to equivalent
> C++
> > structs in place. I am wondering if we should try to consistently always
> provide
> > equivalent C++ structs and type mapping, or if it is okay to sometimes do it
> and
> > sometimes use the Mojo types directly. If we want to go for consistency, we
> > should add the type mapping immediately when we introduce a new Mojo struct.

> 
> I was discussing something similar yesterday, and
> my understanding is that:
> - if there is a C++ struct:
> -- it's OK to use [Native] and use C++-in-mojo
> -- it's even better to have a mojo type + typemappings
> - but if there isn't a C++ equivalent, I would go
> ahead and use mojom everywhere, which is what
> I'm kind of doing here.
> In this particular case, VideoFrameInfo is only
> used in this particular interface, so it doesn't
> matter much.

 content/common/BUILD.gn lgtm

[mcasas, 2016-10-11 19:55:20]

The CQ bit was checked by mcasas@chromium.org

[mcasas, 2016-10-11 19:55:21]

The patchset sent to the CQ was uploaded after l-g-t-m from tsepez@chromium.org,
chfremer@chromium.org
Link to the patchset: https://codereview.chromium.org/2409893003/#ps120001
(title: "rebase content/common/BUILD.gn")

[commit-bot: I haz the power, 2016-10-11 19:55:55]

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-10-11 20:01:09]

Description was changed from

==========
VideoCapture: more migration IPC-->mojo, part 5

This CL migrates the video capture messages
VideoCaptureMsg_BufferReady and FreeBuffer
to mojom. 

This step of the migration was quite straightforward,
most of the +- lines come from unittest adjustments,
and also I threw away some unused code in 
video_capture_host_unittest.cc.

BUG=651897
==========

to

==========
VideoCapture: more migration IPC-->mojo, part 5

This CL migrates the video capture messages
VideoCaptureMsg_BufferReady and FreeBuffer
to mojom. 

This step of the migration was quite straightforward,
most of the +- lines come from unittest adjustments,
and also I threw away some unused code in 
video_capture_host_unittest.cc.

BUG=651897
==========

[commit-bot: I haz the power, 2016-10-11 20:01:11]

Committed patchset #2 (id:120001)

[commit-bot: I haz the power, 2016-10-11 20:03:45]

Description was changed from

==========
VideoCapture: more migration IPC-->mojo, part 5

This CL migrates the video capture messages
VideoCaptureMsg_BufferReady and FreeBuffer
to mojom. 

This step of the migration was quite straightforward,
most of the +- lines come from unittest adjustments,
and also I threw away some unused code in 
video_capture_host_unittest.cc.

BUG=651897
==========

to

==========
VideoCapture: more migration IPC-->mojo, part 5

This CL migrates the video capture messages
VideoCaptureMsg_BufferReady and FreeBuffer
to mojom.

This step of the migration was quite straightforward,
most of the +- lines come from unittest adjustments,
and also I threw away some unused code in
video_capture_host_unittest.cc.

BUG=651897

Committed: https://crrev.com/2ff39f629a774ee513cc69d831d78908a6953e9d
Cr-Commit-Position: refs/heads/master@{#424520}
==========

[commit-bot: I haz the power, 2016-10-11 20:03:46]

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