mozart: Introduce new view manager interfaces.

mozart: Introduce new view manager interfaces.

This change adds mojom interfaces for the new Mozart view manager.
Mozart is different from the old view manager in several ways:

- It does not require a C++ client library to use it.
- The overall design is more centralized.  The view manager keeps
  track of the state of all views and mediates interactions between
  them.  This significantly reduces the complexity of using these
  interfaces safely.
- The view manager supports basic layout negotiations between views.
- Only view management concerns are addressed by the core view
  interfaces.  Other concerns, such as input, will be addressed by
  services which are associated with views but managed separately.

R=abarth@chromium.org, jamesr@chromium.org

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

[jeffbrown, 2015-10-24 02:39:23]

jeffbrown@google.com changed reviewers:
+ abarth@google.com, jamesr@chromium.org

[abarth-chromium, 2015-10-24 05:09:29]

abarth@chromium.org changed reviewers:
+ abarth@chromium.org

[abarth-chromium, 2015-10-24 05:09:30]

This looks great.  LGTM, but you should obviously get jamesr to review it as
well.

You seem to have dropped the notion of an unbounded BoxConstraints.  That might
well be a sensible simplification, but you should be sure to consider the
following situation;

- The parent view contains a vertically scrolling list of child views.
- What value should the parent view pass to the child as its max_height?

In principle, the child can be as tall as it likes because the parent will
simply clip it and provide an affordance for scrolling.

Another thing to consider is whether you want to include a cull rect.  Suppose
the parent clips the child.  We might want the child to avoid producing pixels /
consuming resources for aspects of its view outside of the clip rect.  We
probably should worry about that in a later iteration though.  I only mention it
because of the comment below about eventually ending up with multiple walks of
the view tree.

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
File mojo/services/ui/views/interfaces/layouts.mojom (right):

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:54: // will already have an
invalidation mechanism in place.
The way we handle this issue in Flutter is that we have multiple traversals of
the tree.  For example, it's usually possible to change theme colors without
needing to trigger a layout.  Instead, the various views just need to repaint.

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:64: };
We'll probably need a bunch more metrics about the display here eventually.  For
example, the layout of a view will probably depend on the overall screen size.

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
File mojo/services/ui/views/interfaces/view_trees.mojom (right):

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/view_trees.mojom:49: // Requests that the view
tree host's OnLayout() method be called to compute a
s/view tree host's/view tree's/

[jamesr, 2015-10-26 19:35:39]

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
File mojo/services/ui/views/interfaces/layouts.mojom (right):

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:32: // Must be >= 0.
we could express this constraint in the type system - 'uint32'

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:36: // Must be >= |min_width|.
we don't have a way to validate on this automatically, though

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:56: // The size constraints for
the child in pixels.
"in pixels" is ambiguous - what sort of pixels?

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:60: // of one logical pixel,
assuming pixels are square.  This value changes
what uses logical pixels and what uses device pixels in this scheme?

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:63: float device_pixel_ratio =
1.0;
seems a bit odd to have this be a constraint on a particular view

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
File mojo/services/ui/views/interfaces/view_provider.mojom (right):

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/view_provider.mojom:25: (ViewToken
view_token);
what are the requirements for |view_token|? is the implementation of CreateView
responsible for minting tokens, or should it query those from somewhere else? if
it has to mint tokens does it need to make sure the tokens are locally unique or
globally unique?

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
File mojo/services/ui/views/interfaces/views.mojom (right):

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/views.mojom:162: // will assume that the view
host's layout is not dependent on knowledge
is 'view host' here equivalent to 'parent'? having both 'child' and 'host' feels
a bit confusing

i can imagine cases where the parent's layout does not depend on the child's
size but in order to actually submit frames referencing the child the parent
must know the surface id and size of the surface the child emits. how does it
acquire these when setting |provide_size| == false?

[jeffbrown, 2015-10-27 01:49:07]

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
File mojo/services/ui/views/interfaces/layouts.mojom (right):

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:32: // Must be >= 0.
On 2015/10/26 19:35:38, jamesr wrote:
> we could express this constraint in the type system - 'uint32'

We could.  I was debating whether to use uint32 or int32.  I ultimately settled
on int32 to follow the pattern of mojo.Point and mojo.Rect which are likely to
be used in tandem with these box constraints.

In general I would like to avoid situations where clients might inadvertently
compare signed and unsigned values, especially given that some languages don't
even support unsigned types.

What do you think?

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:36: // Must be >= |min_width|.
On 2015/10/26 19:35:38, jamesr wrote:
> we don't have a way to validate on this automatically, though

True, which is why it's documented.  The implementation will close the
connection on any client that passes an invalid value here.

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:54: // will already have an
invalidation mechanism in place.
On 2015/10/24 05:09:30, abarth-chromium wrote:
> The way we handle this issue in Flutter is that we have multiple traversals of
> the tree.  For example, it's usually possible to change theme colors without
> needing to trigger a layout.  Instead, the various views just need to repaint.

Hmm.  This bears further consideration.  We may need other ways to propagate
contextual information.  I think a lot of this design pivots on how we will
synchronize rendering across the view tree.

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:56: // The size constraints for
the child in pixels.
On 2015/10/26 19:35:38, jamesr wrote:
> "in pixels" is ambiguous - what sort of pixels?

Logical pixels.  I'll clarify the docs.

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:60: // of one logical pixel,
assuming pixels are square.  This value changes
On 2015/10/26 19:35:38, jamesr wrote:
> what uses logical pixels and what uses device pixels in this scheme?

Everything here uses integer device pixels.  The assumption is that the view's
framebuffer will be rendered at that resolution (but the general case is more
complicated).

That said, I might not be using the terminology properly. It can get a bit muddy
especially when output is composed or redirected.  It would be good to settle on
consistent definitions for our coordinate systems.

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:63: float device_pixel_ratio =
1.0;
On 2015/10/26 19:35:38, jamesr wrote:
> seems a bit odd to have this be a constraint on a particular view

It's not a constraint.  It's a parameter that's needed to interpret the
dimensions of the layout.

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/layouts.mojom:64: };
On 2015/10/24 05:09:30, abarth-chromium wrote:
> We'll probably need a bunch more metrics about the display here eventually. 
For
> example, the layout of a view will probably depend on the overall screen size.

I don't think views should care about the overall screen size.  They should do
the best they can with the real-estate they are given.  Apps using display size
for measurement has caused significant compatibility issues for Android and made
it difficult to support multi-window use-cases and the like.

If we want apps to lay out differently on phones vs. tablets vs. watches vs.
laptops then we should find ways of expressing the essential underlying
qualities.  (Here there be dragons.)

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
File mojo/services/ui/views/interfaces/view_provider.mojom (right):

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/view_provider.mojom:25: (ViewToken
view_token);
On 2015/10/26 19:35:38, jamesr wrote:
> what are the requirements for |view_token|? is the implementation of
CreateView
> responsible for minting tokens, or should it query those from somewhere else?
if
> it has to mint tokens does it need to make sure the tokens are locally unique
or
> globally unique?

It's minted by the view manager when the view is registered.

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
File mojo/services/ui/views/interfaces/view_trees.mojom (right):

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/view_trees.mojom:49: // Requests that the view
tree host's OnLayout() method be called to compute a
On 2015/10/24 05:09:30, abarth-chromium wrote:
> s/view tree host's/view tree's/

Done.

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
File mojo/services/ui/views/interfaces/views.mojom (right):

https://codereview.chromium.org/1410693003/diff/1/mojo/services/ui/views/inte...
mojo/services/ui/views/interfaces/views.mojom:162: // will assume that the view
host's layout is not dependent on knowledge
On 2015/10/26 19:35:38, jamesr wrote:
> is 'view host' here equivalent to 'parent'? having both 'child' and 'host'
feels
> a bit confusing
> 
> i can imagine cases where the parent's layout does not depend on the child's
> size but in order to actually submit frames referencing the child the parent
> must know the surface id and size of the surface the child emits. how does it
> acquire these when setting |provide_size| == false?

Yeah, I hate referring to the "host" here.  There's really one object (the view)
with an dual interface.  I'll see if I can tidy this up.

Anyhow, I think you're right.  Given how Surfaces works today, the parent will
always need the size of the child, otherwise the content will get clipped (or
stretched?).

There are some bigger questions lurking here such as whether the view tree
should have a single coordinated layout phase.  I will probably end up
redesigning this entirely.

But for now, maybe I will just delete provide_size.  The same concept might come
back in a different form later.

[qsr, 2015-10-27 10:51:25]

qsr@chromium.org changed reviewers:
+ qsr@chromium.org

[qsr, 2015-10-27 10:51:25]

https://codereview.chromium.org/1410693003/diff/40001/mojo/services/ui/views/...
File mojo/services/ui/views/interfaces/view_provider.mojom (right):

https://codereview.chromium.org/1410693003/diff/40001/mojo/services/ui/views/...
mojo/services/ui/views/interfaces/view_provider.mojom:22: // The |view_token|
must
This comment is incomplete

[jeffbrown, 2015-10-27 22:48:46]

https://codereview.chromium.org/1410693003/diff/40001/mojo/services/ui/views/...
File mojo/services/ui/views/interfaces/view_provider.mojom (right):

https://codereview.chromium.org/1410693003/diff/40001/mojo/services/ui/views/...
mojo/services/ui/views/interfaces/view_provider.mojom:22: // The |view_token|
must
On 2015/10/27 10:51:25, qsr wrote:
> This comment is incomplete

Whoops!

[jamesr, 2015-10-27 22:59:06]

We'll continue to iterate on layout, etc, but lgtm to land this for now

[jeffbrown, 2015-10-28 01:43:38]

Committed patchset #6 (id:100001) manually as
a997cec7d0e0133df53f2be9070e0a6086347acd (presubmit successful).