Use compositor_frame typemap in Blink

Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink.
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

TBR=danakj@chromium.com,sievers@chromium.org
BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/8f40538bf3fb692a3c0f1352c4294b0f35b465f6
Cr-Commit-Position: refs/heads/master@{#416022}

[xlai (Olivia), 2016-08-25 20:46:42]

Description was changed from

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink. Here, I added a function
   SubmitCompositorFrame that use cc.mojom.CompositorFrame. The implementation
of
   this function is currently empty; I'll fill it up (with complex handling on
   browser side) in future CLs.
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

BUG=629566
==========

to

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink. Here, I added a function
   SubmitCompositorFrame that use cc.mojom.CompositorFrame. The implementation
of
   this function is currently empty; I'll fill it up (with complex handling on
   browser side) in future CLs.
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[xlai (Olivia), 2016-08-25 20:46:42]

Description was changed from

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink. Here, I added a function
   SubmitCompositorFrame that use cc.mojom.CompositorFrame. The implementation
of
   this function is currently empty; I'll fill it up (with complex handling on
   browser side) in future CLs.
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink. Here, I added a function
   SubmitCompositorFrame that use cc.mojom.CompositorFrame. The implementation
of
   this function is currently empty; I'll fill it up (with complex handling on
   browser side) in future CLs.
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[xlai (Olivia), 2016-08-25 20:49:16]

Description was changed from

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink. Here, I added a function
   SubmitCompositorFrame that use cc.mojom.CompositorFrame. The implementation
of
   this function is currently empty; I'll fill it up (with complex handling on
   browser side) in future CLs.
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink. Here, I added a function
   SubmitCompositorFrame that use cc.mojom.CompositorFrame. The implementation
of
   this function is currently empty; I'll fill it up (with complex handling on
   browser side) in future CLs.
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[xlai (Olivia), 2016-08-25 20:49:16]

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

[xlai (Olivia), 2016-08-25 20:57:17]

@dcheng: Before I send this CL to more reviewers, I would like you 
to review first. Previously we had e-mail conversion
about code-bloating concern by changing struct_traits of 
dependent types of compositor_frame to partial templates. Now
that issue has been solved (crbug.com/632061) and I can make
all these struct_traits to share DataView between Chromium and Blink.
More explanation is on the description of this CL.

[xlai (Olivia), 2016-08-29 14:29:36]

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

[commit-bot: I haz the power, 2016-08-29 14:30:01]

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-08-29 14:34:02]

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

[commit-bot: I haz the power, 2016-08-29 14:34:03]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[xlai (Olivia), 2016-08-29 15:29:14]

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

[commit-bot: I haz the power, 2016-08-29 15:29:33]

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-08-29 16:29:41]

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

[commit-bot: I haz the power, 2016-08-29 16:29:42]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[xlai (Olivia), 2016-08-29 17:26:21]

ping @dcheng.

[xlai (Olivia), 2016-08-29 19:15:18]

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

[commit-bot: I haz the power, 2016-08-29 19:51:04]

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

[dcheng, 2016-08-29 20:10:37]

LGTM with one nit and one question

https://codereview.chromium.org/2285433002/diff/40001/cc/ipc/compositor_frame...
File cc/ipc/compositor_frame_struct_traits.h (right):

https://codereview.chromium.org/2285433002/diff/40001/cc/ipc/compositor_frame...
cc/ipc/compositor_frame_struct_traits.h:8: #include
"cc/ipc/compositor_frame.mojom-shared.h"
I guess this is code that's shared by the Chromium and Blink variants. Do you
know if it's documented anywhere?

(This doesn't block the CL, I'm jut trying to figure out what we have
documented)

https://codereview.chromium.org/2285433002/diff/40001/content/browser/rendere...
File content/browser/renderer_host/offscreen_canvas_surface_impl.cc (right):

https://codereview.chromium.org/2285433002/diff/40001/content/browser/rendere...
content/browser/renderer_host/offscreen_canvas_surface_impl.cc:79: //
TODO(563852): Implement OffscreenCanvas commit flow.
Can we just put this change in the CL that implements it?

(I guess this helps enforce that it compiles in both variants, but it's also
important for mojo reviewers to review IPC changes in the actual context of the
change)

[xlai (Olivia), 2016-08-29 21:00:17]

xlai@chromium.org changed reviewers:
+ danakj@chromium.org, sievers@chromium.org

[xlai (Olivia), 2016-08-29 21:06:12]

xlai@chromium.org changed reviewers:
+ junov@chromium.org, sadrul@chromium.org, yzshen@chromium.org

[xlai (Olivia), 2016-08-29 21:11:33]

The CQ bit was unchecked by xlai@chromium.org

[xlai (Olivia), 2016-08-29 21:29:52]

Description was changed from

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink. Here, I added a function
   SubmitCompositorFrame that use cc.mojom.CompositorFrame. The implementation
of
   this function is currently empty; I'll fill it up (with complex handling on
   browser side) in future CLs.
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink. 
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[xlai (Olivia), 2016-08-29 21:43:11]

To all reviewers: please only review the GN build files (including .gn, .gni and
.typemap files) in the respective folders. 
The rest of code (struct_traits, .mojom, certain ipc or common folders) have
been taken care by IPC owner already.

+danakj@: ui/gfx and cc/ipc.
+sievers@: content/
+junov@: skia/
+yzshen@: mojo/
+pdr@: third_party/WebKit/public/
+sadrul@: ui/events/

https://codereview.chromium.org/2285433002/diff/40001/cc/ipc/compositor_frame...
File cc/ipc/compositor_frame_struct_traits.h (right):

https://codereview.chromium.org/2285433002/diff/40001/cc/ipc/compositor_frame...
cc/ipc/compositor_frame_struct_traits.h:8: #include
"cc/ipc/compositor_frame.mojom-shared.h"
On 2016/08/29 20:10:37, dcheng wrote:
> I guess this is code that's shared by the Chromium and Blink variants. Do you
> know if it's documented anywhere?
> 
> (This doesn't block the CL, I'm jut trying to figure out what we have
> documented)

This is something newly implemented in crbug.com/632061, AFAIK, it hasn't been
documented yet. I'll contact yzshen@ and see if I can help adding documentation
to mojo wiki page (probably with this CL as an example for other developers
too).

https://codereview.chromium.org/2285433002/diff/40001/content/browser/rendere...
File content/browser/renderer_host/offscreen_canvas_surface_impl.cc (right):

https://codereview.chromium.org/2285433002/diff/40001/content/browser/rendere...
content/browser/renderer_host/offscreen_canvas_surface_impl.cc:79: //
TODO(563852): Implement OffscreenCanvas commit flow.
On 2016/08/29 20:10:37, dcheng wrote:
> Can we just put this change in the CL that implements it?
> 
> (I guess this helps enforce that it compiles in both variants, but it's also
> important for mojo reviewers to review IPC changes in the actual context of
the
> change)

No problems. Since I have already found that the patch compiles in all the
trybots, I remove this part and only put it back in next CL.

[xlai (Olivia), 2016-08-30 19:21:52]

xlai@chromium.org changed reviewers:
+ pdr@chromium.org

[xlai (Olivia), 2016-08-30 19:22:49]

+danakj@: ui/gfx and cc/ipc.
+sievers@: content/
+junov@: skia/
+yzshen@: mojo/
+pdr@: third_party/WebKit/public/
+sadrul@: ui/events/

Please review GN build files in the respective folders. Thanks a lot!

[Justin Novosad, 2016-08-30 20:17:17]

lgtm for skia

[Justin Novosad, 2016-08-30 20:17:36]

With nits...

https://codereview.chromium.org/2285433002/diff/60001/skia/public/interfaces/...
File skia/public/interfaces/image_filter.typemap (right):

https://codereview.chromium.org/2285433002/diff/60001/skia/public/interfaces/...
skia/public/interfaces/image_filter.typemap:9:
"//skia/public/interfaces:struct_traits",
Could you put this on one line, like before?

https://codereview.chromium.org/2285433002/diff/60001/skia/public/interfaces/...
skia/public/interfaces/image_filter.typemap:12:
"//skia/public/interfaces:struct_traits",
Same here.

[xlai (Olivia), 2016-08-30 21:33:12]

https://codereview.chromium.org/2285433002/diff/60001/skia/public/interfaces/...
File skia/public/interfaces/image_filter.typemap (right):

https://codereview.chromium.org/2285433002/diff/60001/skia/public/interfaces/...
skia/public/interfaces/image_filter.typemap:9:
"//skia/public/interfaces:struct_traits",
On 2016/08/30 20:17:36, Justin Novosad wrote:
> Could you put this on one line, like before?

I tried to change it. But when I upload the patch, the git cl presubmit
complains that I need to do gn format. After doing gn format on this file, it's
reverted back to this format again.

[pdr., 2016-08-30 23:33:39]

pdr@chromium.org changed reviewers:
+ esprehn@chromium.org

[pdr., 2016-08-30 23:55:52]

I don't have a lot of experience with mojo yet so I'd prefer if someone else
reviewed WebKit/public. +reviewer esprehn, could you please take a look?

https://codereview.chromium.org/2285433002/diff/60001/third_party/WebKit/publ...
File third_party/WebKit/public/BUILD.gn (right):

https://codereview.chromium.org/2285433002/diff/60001/third_party/WebKit/publ...
third_party/WebKit/public/BUILD.gn:247: "//cc/ipc:interfaces",
It looks like you took a lot of care to only pull in surfaceid before, which had
few dependencies. The cc/ipc interfaces depend on quite a lot.. do we need to
worry about that?

[esprehn, 2016-08-31 00:04:00]

Maybe I don't understand this but it seems to be pulling the cc data structures
into blink, plus all of the deps of it (ui/gfx, gpu/, etc.)

None of those are allowed inside blink above platform/, and we haven't been
allowing them in IPCs either since we allow mojo everywhere.

https://codereview.chromium.org/2285433002/diff/60001/cc/ipc/compositor_frame...
File cc/ipc/compositor_frame_for_blink.typemap (right):

https://codereview.chromium.org/2285433002/diff/60001/cc/ipc/compositor_frame...
cc/ipc/compositor_frame_for_blink.typemap:40: type_mappings = [
"cc.mojom.CompositorFrame=cc::CompositorFrame[move_only]" ]
This means inside blink we end up with a cc::CompositorFrame object?

That's not actually allowed per layering, it pulls in all of this stuff ex.
https://cs.chromium.org/chromium/src/cc/output/compositor_frame_metadata.h?sq...

[xlai (Olivia), 2016-08-31 01:03:30]

I will address both pdr.@ and esprehn@'s concerns together.

First of all, cc::CompositorFrame is allowed to be used in Blink platform layer;
there is already a bunch of cc objects such as cc::SurfaceId that's used in
Blink platform. This restriction is loosened recently in order to avoid too much
plumbing into content/ layer. Three months ago, before embarking on the project
of OffscreenCanvas commit flow, I discussed this issue with danakj@, jbroman@,
weiliangc@, junov@ and other folks who're familiar with both cc and
Blink and was informed that this is the new direction to move towards. In fact,
this
is the primary reason why I use mojo because mojo allows me to directly send
compositorFrame from Blink.

Secondly, this one does NOT expose the dependent objects of
compositor_frame.mojom into Blink. Three weeks ago we had this concern and
therefore yzshen@ fixed crbug.com/632061 in order to allow me to avoid this
problem. I say this because of three aspects:
1. In this CL, //cc/ipc:interfaces is just the "deps" for the
offscreen_canvas_surface.mojom; this is indirect dependency; this indirect 
dependency is necessary because compositor_frame.mojom is a complicated data
type that needs its dependent types to support its type mapping. Also,
indirect dependency is everything; many things in Blink will eventually depend
on
//base when we trace the dependency graph. There's no difference here.
2. //cc/ipc::interfaces are mojom types, not custom types. It doesn't mean that
all
of a sudden I can start manipulating one of the dependent type (say a data type
in
or ui/gfx/) in Blink. 
3. Even if //cc/ipc::interfaces contain mojom types that we don't want it to be
in Blink,
those mojom types are not exposed in Blink's mojom file, because only 
compositor_frame_for_blink.typemap is added to Blink, not the rest of typemaps
(If I
add XXX.typemap to Blink then it's valid to raise the concern that XXX shouldn't
be used
in Blink and so on; but here I don't). Inside the typemap, only 
//cc/output/compositor_frame.h is the public_header. That means
users in Blink can only use CompositorFrame in mojo calls, not any other mojom
data types.

I hope this address the concern about Blink dependencies. 


On 2016/08/31 00:04:00, esprehn wrote:
> Maybe I don't understand this but it seems to be pulling the cc data
structures
> into blink, plus all of the deps of it (ui/gfx, gpu/, etc.)
> 
> None of those are allowed inside blink above platform/, and we haven't been
> allowing them in IPCs either since we allow mojo everywhere.
> 
>
https://codereview.chromium.org/2285433002/diff/60001/cc/ipc/compositor_frame...
> File cc/ipc/compositor_frame_for_blink.typemap (right):
> 
>
https://codereview.chromium.org/2285433002/diff/60001/cc/ipc/compositor_frame...
> cc/ipc/compositor_frame_for_blink.typemap:40: type_mappings = [
> "cc.mojom.CompositorFrame=cc::CompositorFrame[move_only]" ]
> This means inside blink we end up with a cc::CompositorFrame object?
> 
> That's not actually allowed per layering, it pulls in all of this stuff ex.
>
https://cs.chromium.org/chromium/src/cc/output/compositor_frame_metadata.h?sq...

[pdr., 2016-08-31 17:39:53]

On 2016/08/31 at 01:03:30, xlai wrote:

Thank you for the detailed response. That addresses my concern about the extra
dependencies.

[esprehn, 2016-08-31 17:46:04]

I don't understand how "this one does NOT expose the dependent objects of
compositor_frame.mojom into Blink" if we're getting a cc:CompositorFrame object
inside blink (the C++ object, this isn't about the mojo types), we're getting
all of those nested objects inside it. Those objects mean the usage of
cc:CompositorFrame will be limited to platform, you won't be able to send these
mojo IPCs from inside modules/ or in the canvas code.

Where did you plan to send these IPCs from?

[xlai (Olivia), 2016-08-31 19:26:53]

I intend to make mojo IPC calls from Source/platform/graphics/ and I've already
restrict
such a place by adding
"//third_party/WebKit/public:offscreen_canvas_mojo_bindings_blink"
to Source/platform/BUILD.gn. That means, nobody in core/ and modules/ can see
that
generated blink mojom files from offscreen_canvas_surface.mojom.

I don't do any changes to Source/modules/ as your concern. Note that 
offscreen_canvas_surface.mojom sits inside public/platform/ (it's just the
subfolder
has a name "modules"; you might be misled by the name and thought I'm changing
modules/). 

Also, we are allowed to include cc::CompositorFrame in platform/graphics and use
it 
(See existing DEPS file
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graph...).
Anyone trying to use cc objects outside that folder will violate existing DEPS
and 
I don't change the existing situation.

Just now I double check the generated blink mojom file
(i.e. offscreen_canvas_surface.mojom-blink.h), it includes cc::CompositorFrame
only, no other dependent types are included. I traced the include paths all the
way to
 generated cc folder and only after many levels of #include, I eventually see 
those dependent types that shouldn't be in Blink. But what's wrong with such an
indirect way
of include? There are already many cc objects that are included in classes in
platform/, 
which is then included by classes in core/, which is then included by classes in
modules/; 
as long as we follow the existing dependency path and don't directly include cc
objects in 
modules/, it is fine. I am just doing exactly the same here.

One more extra step I've added to ensure correct dependency is to isolate my
change to 
only offscreen_canvas_surface.mojom
(See my changes in third_party/WebKit/public/BUILD.gn). I double check the
generated mojom files
from other .mojom file in Blink, NOBODY includes the cc stuffs on which mine is
depending; and they
can't.

My description above might be too long and a bit messy (I was thinking hard on
how to organize my
argument; I know a lot of things via repeated trial-and-error in GN build but
it's hard to articulate);
but in a summary:

1. Only cc::compositorFrame include those dependent types, including those data
types that you say
   cannot be exposed in Blink. Nowhere else directly include the dependent
types.
2. Only generated mojom-blink file from offscreen_canvas_surface.mojom include
cc::CompositorFrame.
   All the other generated mojom files do not include that (and is unable to
include that because the
   dependency is isolated to offscreen_canvas_surface).
3. Only platform is dependent on generated mojom-blink file from
offscreen_canvas_surface. Other layers
   (e.g. core/) don't.
4. Only offscreen_canvas_surface.mojom can use the CompositorFrame mojom type.
And that's the only thing
   it can use (not its dependent mojom type). And here, type conversion to
custom type only works for
   CompositorFrame.
5. Indirect include and deps are seen in everywhere in the code base (e.g. A in
modules/ include B in
   core/, which then include C in platform/ which then include D in cc/). This
is why my CL compiles--I
   rely on indirect include dependencies.

I hope this address your concern.









On 2016/08/31 17:46:04, esprehn wrote:
> I don't understand how "this one does NOT expose the dependent objects of
> compositor_frame.mojom into Blink" if we're getting a cc:CompositorFrame
object
> inside blink (the C++ object, this isn't about the mojo types), we're getting
> all of those nested objects inside it. Those objects mean the usage of
> cc:CompositorFrame will be limited to platform, you won't be able to send
these
> mojo IPCs from inside modules/ or in the canvas code.
> 
> Where did you plan to send these IPCs from?

[esprehn, 2016-08-31 23:12:13]

Yeah that seems fine. lgtm

[yzshen1, 2016-09-01 00:02:54]

LGTM with a few nits.

Thanks!

https://codereview.chromium.org/2285433002/diff/60001/mojo/common/BUILD.gn
File mojo/common/BUILD.gn (right):

https://codereview.chromium.org/2285433002/diff/60001/mojo/common/BUILD.gn#ne...
mojo/common/BUILD.gn:93: group("struct_traits") {
Can we delete this target and rename the one below to "struct_traits"?

https://codereview.chromium.org/2285433002/diff/60001/mojo/common/common_cust...
File mojo/common/common_custom_types_struct_traits.cc (right):

https://codereview.chromium.org/2285433002/diff/60001/mojo/common/common_cust...
mojo/common/common_custom_types_struct_traits.cc:16: return !version.IsValid();
can these short methods stay in the .h file?

That way the compilers may inline them to be faster.

https://codereview.chromium.org/2285433002/diff/60001/skia/public/interfaces/...
File skia/public/interfaces/BUILD.gn (right):

https://codereview.chromium.org/2285433002/diff/60001/skia/public/interfaces/...
skia/public/interfaces/BUILD.gn:41: group("struct_traits") {
Can we delete this and rename struct_traits_sources to struct_traits?

https://codereview.chromium.org/2285433002/diff/60001/third_party/WebKit/publ...
File third_party/WebKit/public/BUILD.gn (right):

https://codereview.chromium.org/2285433002/diff/60001/third_party/WebKit/publ...
third_party/WebKit/public/BUILD.gn:251: use_new_wrapper_types = true
you could delete this line, true is the default value.

https://codereview.chromium.org/2285433002/diff/60001/ui/events/mojo/BUILD.gn
File ui/events/mojo/BUILD.gn (right):

https://codereview.chromium.org/2285433002/diff/60001/ui/events/mojo/BUILD.gn...
ui/events/mojo/BUILD.gn:38: ":struct_traits_sources",
Can we delete this and rename struct_traits_sources to struct_traits? (Same
comment for some other files.)

[sadrul, 2016-09-01 05:37:59]

stamp lgtm with yzshen@'s comments addressed.

[xlai (Olivia), 2016-09-01 15:23:44]

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

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

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-01 15:27:47]

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

[commit-bot: I haz the power, 2016-09-01 15:27:48]

Dry run: Try jobs failed on following builders:
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[xlai (Olivia), 2016-09-01 16:00:25]

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

[commit-bot: I haz the power, 2016-09-01 16:00:44]

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

[xlai (Olivia), 2016-09-01 16:57:44]

https://codereview.chromium.org/2285433002/diff/60001/mojo/common/BUILD.gn
File mojo/common/BUILD.gn (right):

https://codereview.chromium.org/2285433002/diff/60001/mojo/common/BUILD.gn#ne...
mojo/common/BUILD.gn:93: group("struct_traits") {
On 2016/09/01 00:02:54, yzshen1 wrote:
> Can we delete this target and rename the one below to "struct_traits"?

Done here and elsewhere.

https://codereview.chromium.org/2285433002/diff/60001/mojo/common/common_cust...
File mojo/common/common_custom_types_struct_traits.cc (right):

https://codereview.chromium.org/2285433002/diff/60001/mojo/common/common_cust...
mojo/common/common_custom_types_struct_traits.cc:16: return !version.IsValid();
On 2016/09/01 00:02:54, yzshen1 wrote:
> can these short methods stay in the .h file?
> 
> That way the compilers may inline them to be faster.

Done.

https://codereview.chromium.org/2285433002/diff/60001/third_party/WebKit/publ...
File third_party/WebKit/public/BUILD.gn (right):

https://codereview.chromium.org/2285433002/diff/60001/third_party/WebKit/publ...
third_party/WebKit/public/BUILD.gn:251: use_new_wrapper_types = true
On 2016/09/01 00:02:54, yzshen1 wrote:
> you could delete this line, true is the default value.

Done.

[xlai (Olivia), 2016-09-01 17:02:36]

Description was changed from

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink. 
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink. 
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

TBR=danakj@chromium.com,sievers@chromium.org
BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

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

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

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

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[xlai (Olivia), 2016-09-01 18:45:21]

The CQ bit was checked by xlai@chromium.org

[xlai (Olivia), 2016-09-01 18:45:21]

The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org,
sadrul@chromium.org, esprehn@chromium.org, yzshen@chromium.org,
junov@chromium.org
Link to the patchset: https://codereview.chromium.org/2285433002/#ps120001
(title: "Adapt to new change after rebase")

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

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-01 19:46:39]

Description was changed from

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink. 
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

TBR=danakj@chromium.com,sievers@chromium.org
BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink. 
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

TBR=danakj@chromium.com,sievers@chromium.org
BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[commit-bot: I haz the power, 2016-09-01 19:46:41]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-09-01 19:48:21]

Description was changed from

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink. 
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

TBR=danakj@chromium.com,sievers@chromium.org
BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Use compositor_frame typemap in Blink

After mojo implementation change to share DataView between Blink and Chromium
(crbug.com/632061 fixed), now it is possible to use cc.mojom.CompositorFrame and
its typemap in Blink. Previously this attempt failed because of the need to
convert all struct_traits of  compositor_frame's dependent types to partial
templates (that would cause code bloating) or the need to include all typemaps
of dependent types to Blink (that would violate Blink-Chromium dependency
restriction); but now neither of these is needed.

This CL does the following:
1. It makes all the struct_traits of dependent types of compositor_frame.mojom
   to use shared DataView.
2. It extracts the struct_traits source files and put them as a standalone
   build target, which is then referenced by their coresponding typemap as well
   as the other struct_traits target that depend on them. In this way, the
   struct traits source files form a build dependency graph just as same as the
   mojom files. This allows Blink to include the cc struct traits (with proper
   dependency beneath it) to compile the compositor_frame typemap.
3. Ultimately, the usage of compositor_frame happens in
   offscreen_canvas_surface.mojom in Blink.
4. The offscreen_canvas_surface.mojom is isolated in build (see third_party/
   WebKit/public/BUILD) because it includes compositor_frame.h (a super complex
   data type that includes a lot of other things) that would pollute
   the other Blink mojom files. This is not to interfere other existing or
   future mojom files in Blink that do not want to include compositor_frame. I
   put these in the comment. Since it is an isolated build target, I add it
   to deps in WebKit/Source/platform/BUILD.gn and content/browser/BUILD.gn, the
   only two places that use offscreen_canvas_surface.

TBR=danakj@chromium.com,sievers@chromium.org
BUG=629566
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/8f40538bf3fb692a3c0f1352c4294b0f35b465f6
Cr-Commit-Position: refs/heads/master@{#416022}
==========

[commit-bot: I haz the power, 2016-09-01 19:48:23]

Patchset 7 (id:??) landed as
https://crrev.com/8f40538bf3fb692a3c0f1352c4294b0f35b465f6
Cr-Commit-Position: refs/heads/master@{#416022}