Mozart: Add hit testing interfaces.

Mozart: Add hit testing interfaces.

Define Mojo interfaces for hit testing functionality modeled after
Flutter's hit test traversal process.

Each node can supply a hit test behavior to control how hit testing
should occur within its bounds.  The key properties are visibility,
pruning, and a hit rect.

Visibility is one of |INVISIBLE|, |TRANSLUCENT|, and |OPAQUE|.
This property determines whether a node can be hit and its effect
upon subsequent traversals once hit.

Pruning determines whether children of a node will be hit tested
at all.  This can be used to suppress hit testing for a subgraph.

And the hit rect is just a finer specification of the hittable region
within a node's bounds.  In the future, this will likely expand
to describe more complex regions.

The results of a hit test are described structurally as a tree which
records the event dispatch order for nodes which are hit as well as
the path by which they were reached.

In general, the dispatch order goes from the most specific hit node
outwards which can be significant for certain operations.

BUG=
R=abarth@google.com

Committed: https://chromium.googlesource.com/external/mojo/+/c1287c19972d5010f0c0ada3464a0d3e459e7480

[jeffbrown, 2016-03-01 08:11:54]

jeffbrown@google.com changed reviewers:
+ abarth@google.com

[jeffbrown, 2016-03-01 08:11:55]

Please let me know what you think.  Thanks!

[abarth, 2016-03-01 17:33:43]

LGTM

https://codereview.chromium.org/1748363002/diff/20001/mojo/services/gfx/compo...
File mojo/services/gfx/composition/interfaces/hit_tests.mojom (right):

https://codereview.chromium.org/1748363002/diff/20001/mojo/services/gfx/compo...
mojo/services/gfx/composition/interfaces/hit_tests.mojom:103: };
I was expecting NodeHit to have an array<NodeHit>, but I guess you just flatten
those up into SceneHit...  Maybe change the docs for HitTestResult to reflect
this?  It current says this is a subtree, but it's got a different tree
structure.

https://codereview.chromium.org/1748363002/diff/20001/mojo/services/gfx/compo...
File mojo/services/gfx/composition/interfaces/nodes.mojom (left):

https://codereview.chromium.org/1748363002/diff/20001/mojo/services/gfx/compo...
mojo/services/gfx/composition/interfaces/nodes.mojom:135: uint32 hit_id =
kHitIdNone;
It looks like you've removed the concept of a hit_id and just used the node_id
instead.  It's slightly more flexible if you like the client assign IDs for hit
testing separately from how they assign IDs for the nodes.  Of course, they're
free to use the node ID for the hit ID, but some clients might want to use
separate systems to assign the IDs.  Specifically, in Flutter, the compositor
might be in charge of assigning node IDs but the framework might want to assign
hit IDs.

[jeffbrown, 2016-03-02 00:51:52]

https://codereview.chromium.org/1748363002/diff/20001/mojo/services/gfx/compo...
File mojo/services/gfx/composition/interfaces/hit_tests.mojom (right):

https://codereview.chromium.org/1748363002/diff/20001/mojo/services/gfx/compo...
mojo/services/gfx/composition/interfaces/hit_tests.mojom:103: };
On 2016/03/01 17:33:43, abarth wrote:
> I was expecting NodeHit to have an array<NodeHit>, but I guess you just
flatten
> those up into SceneHit...  Maybe change the docs for HitTestResult to reflect
> this?  It current says this is a subtree, but it's got a different tree
> structure.

Good point.  I'm not reflecting the entire node structure here because I don't
think we need it, but I should make that clearer.

I'm also not fond of the naming convention.  |NodeHit| is kind of weird when
it's possible for the node to be invisible and only be carrying scene
information.  Open to suggestions.

I think I'm going to try to get rid of the usage of |visible| here.

https://codereview.chromium.org/1748363002/diff/20001/mojo/services/gfx/compo...
File mojo/services/gfx/composition/interfaces/nodes.mojom (left):

https://codereview.chromium.org/1748363002/diff/20001/mojo/services/gfx/compo...
mojo/services/gfx/composition/interfaces/nodes.mojom:135: uint32 hit_id =
kHitIdNone;
On 2016/03/01 17:33:43, abarth wrote:
> It looks like you've removed the concept of a hit_id and just used the node_id
> instead.  It's slightly more flexible if you like the client assign IDs for
hit
> testing separately from how they assign IDs for the nodes.  Of course, they're
> free to use the node ID for the hit ID, but some clients might want to use
> separate systems to assign the IDs.  Specifically, in Flutter, the compositor
> might be in charge of assigning node IDs but the framework might want to
assign
> hit IDs.

*nod*  I got rid of this as part of an exercise to see if we could get away with
something more minimal.  I think I'm going to leave this out for the moment
since clients can perform their own mapping without extra assistance from the
compositor anyhow.  But if it's too painful I might put it back in or add
something else.

[jeffbrown, 2016-03-02 19:18:02]

Description was changed from

==========
Mozart: Add hit testing interfaces.

Define Mojo interfaces for hit testing functionality modeled after
Flutter's hit test traversal process.

Each node can supply a hit test behavior to control how hit testing
should occur within its bounds.  The key properties are visibility,
pruning, and a hit rect.

Visibility is one of |INVISIBLE|, |TRANSLUCENT|, and |OPAQUE|.
This property determines whether a node can be hit and its effect
upon subsequent traversals once hit.

Pruning determines whether children of a node will be hit tested
at all.  This can be used to suppress hit testing for a subgraph.

And the hit rect is just a finer specification of the hittable region
within a node's bounds.  In the future, this will likely expand
to describe more complex regions.

The results of a hit test are described structurally as a tree which
records the event dispatch order for nodes which are hit as well as
the path by which they were reached.

In general, the dispatch order goes from the most specific hit node
outwards which can be significant for certain operations.

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

to

==========
Mozart: Add hit testing interfaces.

Define Mojo interfaces for hit testing functionality modeled after
Flutter's hit test traversal process.

Each node can supply a hit test behavior to control how hit testing
should occur within its bounds.  The key properties are visibility,
pruning, and a hit rect.

Visibility is one of |INVISIBLE|, |TRANSLUCENT|, and |OPAQUE|.
This property determines whether a node can be hit and its effect
upon subsequent traversals once hit.

Pruning determines whether children of a node will be hit tested
at all.  This can be used to suppress hit testing for a subgraph.

And the hit rect is just a finer specification of the hittable region
within a node's bounds.  In the future, this will likely expand
to describe more complex regions.

The results of a hit test are described structurally as a tree which
records the event dispatch order for nodes which are hit as well as
the path by which they were reached.

In general, the dispatch order goes from the most specific hit node
outwards which can be significant for certain operations.

BUG=
R=abarth@google.com

Committed:
https://chromium.googlesource.com/external/mojo/+/c1287c19972d5010f0c0ada3464...
==========

[jeffbrown, 2016-03-02 19:18:04]

Committed patchset #3 (id:40001) manually as
c1287c19972d5010f0c0ada3464a0d3e459e7480 (presubmit successful).