WIP Hittest Component.

components/viz/hittest/public/interfaces/hittest_data.mojom

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+module viz.hittest.mojom;
+
+import "cc/ipc/surface_id.mojom";
+import "ui/gfx/geometry/mojo/geometry.mojom";
+import "ui/gfx/mojo/transform.mojom";
+
+enum HittestRegionFlags { 
+  HITTEST_NONE = 0,

[rjkroege, 2017/06/02 22:45:46]

say what they are.

[gklassen, 2017/06/05 21:32:14]

Done.

+  HITTEST_SURFACE,
+  HITTEST_ASK, 
+  HITTEST_NO_TOUCH_EVENT_HANDLER,
+  HITTEST_IGNORE
+};
+
+struct HittestRegion {
+    cc.mojom.SurfaceId surface_id_;
+    HittestRegionFlags flags_;
+    gfx.mojom.Rect rect_;
+    gfx.mojom.Transform transform_;
+};
+
+struct HittestData {
+  cc.mojom.SurfaceId surface_id_;

[rjkroege, 2017/06/02 22:45:46]

conceivably this should be the FrameSink ID instead

[gklassen, 2017/06/05 21:32:14]

Using FrameSink ID would make things simpler - here is a concern ( that may be
based on a misunderstanding ) - is it possible that the hittest aggregator may
need to manage more than one SurfaceId from the same FrameSinkId? Eg. two
hittestdata objects are received - one old and one new - and the old one needs
to be used until the new surface has been validated?   

+  gfx.mojom.Rect rect_;
+  HittestRegionFlags flags_;
+  array<HittestRegion> regions_; // in z-order

[rjkroege, 2017/06/02 22:45:46]

ascending or descending

+};