WIP Hittest Component.

components/viz/hittest/display_hittest_data.h

Index: components/viz/hittest/display_hittest_data.h
diff --git a/components/viz/hittest/display_hittest_data.h b/components/viz/hittest/display_hittest_data.h
new file mode 100644
index 0000000000000000000000000000000000000000..ae3f57dc3b738dcbca458e9f5f0e7146a6fbb751
--- /dev/null
+++ b/components/viz/hittest/display_hittest_data.h
@@ -0,0 +1,65 @@
+// Copyright 2017 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.
+
+#ifndef COMPONENTS_VIZ_HITTEST_HITTEST_DATA_H_

[rjkroege, 2017/06/07 17:16:45]

HIT_TEST now

Or... use Targeting

[gklassen, 2017/06/07 20:04:44]

Interesting... are you suggesting replacing HitTest with Targetting?   

+#define COMPONENTS_VIZ_HITTEST_HITTEST_DATA_H_
+
+#include <stdint.h>
+
+#include <map>
+#include <memory>
+
+#include "cc/surfaces/surface_id.h"
+#include "cc/surfaces/surface_observer.h"
+#include "components/viz/hittest/hittest_export.h"
+#include "components/viz/hittest/public/interfaces/hittest_data.mojom.h"
+#include "hittest_aggregator.h"
+#include "ui/gfx/geometry/quad_f.h"
+
+namespace viz {
+
+// DiplayHittestData contains the hittest data for the Display.
+//
+// It is designed to be in shared memory so that
+// - the viz process can collect and write the hittest data, and
+// - other processes can access without process hops or mojo calls
+//
+// One instance of this class contains a double buffer of entries -
+// the viz process will write into one half while client processes read from
+// the other.  front_offset_ is used to swap buffers atomically.
+
+class DisplayHittestData {
+ public:
+  static DisplayHittestData* Create();

[rjkroege, 2017/06/07 17:16:45]

embed the cast here? align with the buffer code that I send you the link for?

+  static DisplayHittestData* Create(int size);
+
+  // Build regions from map of active hittest data objects
+  void Build(const HittestDataMap& map, cc::SurfaceId root_surface_id);
+  void Swap();
+
+ private:
+  DisplayHittestData();
+  ~DisplayHittestData();
+
+  void Append(const HittestDataMap& map, cc::SurfaceId root_surface_id);
+  void Append(const HittestDataMap& map,
+              const hittest::mojom::HittestRegionPtr& region);
+
+  struct Element {

[rjkroege, 2017/06/07 17:16:45]

the client side code needs to walk this tree. yes? So where is the client code?
You need to arrange for the lookup code and the aggregation code to share the
definition of the structure?

[gklassen, 2017/06/07 20:04:44]

Yes.  This has been changed to be a structure so that the code that builds the
struct ( HitTestAggregator ) and the code that walks it are distinct and share a
simple POD struct.  This is based on your earlier suggestions and it's much
better.  I hope you like it when you see it. 

+    cc::SurfaceId surface_id_;
+    hittest::mojom::HittestRegionFlags flags_;
+    gfx::Rect rect_;
+    gfx::Transform transform_;
+    int child_count_;
+  };
+
+  base::subtle::Atomic32 front_offset_;

[rjkroege, 2017/06/07 17:16:45]

what's front and what's back?

[gklassen, 2017/06/07 20:04:44]

Front is the portion currently in use for targetting.  Name suggestions welcome.
 I'm not sure if I like it, but it was the simplest thing I could think of that
helped to imply that this indicates where the struct is being read from and not
written to. 

+  int size_;
+  int count_;
+  Element regions_[];
+};
+
+}  // namespace viz

[rjkroege, 2017/06/07 17:16:45]

suppose to be 1 space I think. But I could be wrong.

[gklassen, 2017/06/07 20:04:44]

Done.

+
+#endif  //  COMPONENTS_VIZ_HITTEST_HITTEST_DATA_H_