Borders.

Enable RenderDecoratedBox to draw borders.
Currently supports only solid borders, but of any colour and size, independently controlling each side.

R=abarth@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/5bea9f7842768b9e7cee393f855f521c70b89dfa

[eseidel, 2015-06-04 00:27:13]

eseidel@chromium.org changed reviewers:
+ eseidel@chromium.org, mpcomplete@chromium.org

[eseidel, 2015-06-04 00:27:13]

You need a changelog description. :)

Also, skia has fancier apis for drawing multiple lines like this which we should
probably expose.

[reed1, 2015-06-04 14:24:03]

reed@google.com changed reviewers:
+ reed@google.com

[reed1, 2015-06-04 14:24:03]

Some ideas to potentially simplify memory allocs ...

1. SkPath has a reset()/rewind() call, allowing it to be reused (so you don't
have to "new" another one.

2. canvas.drawPolygon(Point[], bool close, Paint) -- if drawing single-contour
polygons is common, this might be simpler/cheaper at the Dart level than
creating a Path object.

[Hixie, 2015-06-04 16:30:16]

On 2015/06/04 at 14:24:03, reed wrote:
> Some ideas to potentially simplify memory allocs ...
> 
> 1. SkPath has a reset()/rewind() call, allowing it to be reused (so you don't
have to "new" another one.
> 
> 2. canvas.drawPolygon(Point[], bool close, Paint) -- if drawing single-contour
polygons is common, this might be simpler/cheaper at the Dart level than
creating a Path object.

Cool. I'll file bugs to make sure we expose and use these.

[abarth-chromium, 2015-06-04 16:50:34]

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

[abarth-chromium, 2015-06-04 16:50:34]

lgtm

[Matt Perry, 2015-06-04 16:58:33]

https://codereview.chromium.org/1154903006/diff/40001/sky/sdk/lib/framework/r...
File sky/sdk/lib/framework/rendering/box.dart (right):

https://codereview.chromium.org/1154903006/diff/40001/sky/sdk/lib/framework/r...
sky/sdk/lib/framework/rendering/box.dart:361: static const None = const
BorderSide(width: 0.0);
what's our naming scheme for class constants? I've been following the dart style
guide which recommends camelCase:
https://www.dartlang.org/articles/style-guide/#names

https://codereview.chromium.org/1154903006/diff/40001/sky/sdk/lib/framework/r...
sky/sdk/lib/framework/rendering/box.dart:450: path.moveTo(0.0,0.0);
nit: space after ,

[Hixie, 2015-06-04 17:51:04]

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

[Matt Perry, 2015-06-04 17:59:43]

https://codereview.chromium.org/1154903006/diff/40001/sky/sdk/lib/framework/r...
File sky/sdk/lib/framework/rendering/box.dart (right):

https://codereview.chromium.org/1154903006/diff/40001/sky/sdk/lib/framework/r...
sky/sdk/lib/framework/rendering/box.dart:361: static const None = const
BorderSide(width: 0.0);
On 2015/06/04 16:58:33, Matt Perry wrote:
> what's our naming scheme for class constants? I've been following the dart
style
> guide which recommends camelCase:
> https://www.dartlang.org/articles/style-guide/#names

Still curious what the decision was here. Should we:
1. Use CapsStyle naming.
2. Use camelCase naming.
3. Use whichever one we prefer?

[abarth-chromium, 2015-06-04 18:07:30]

On 2015/06/04 at 17:59:43, mpcomplete wrote:
>
https://codereview.chromium.org/1154903006/diff/40001/sky/sdk/lib/framework/r...
> File sky/sdk/lib/framework/rendering/box.dart (right):
> 
>
https://codereview.chromium.org/1154903006/diff/40001/sky/sdk/lib/framework/r...
> sky/sdk/lib/framework/rendering/box.dart:361: static const None = const
BorderSide(width: 0.0);
> On 2015/06/04 16:58:33, Matt Perry wrote:
> > what's our naming scheme for class constants? I've been following the dart
style
> > guide which recommends camelCase:
> > https://www.dartlang.org/articles/style-guide/#names
> 
> Still curious what the decision was here. Should we:
> 1. Use CapsStyle naming.
> 2. Use camelCase naming.
> 3. Use whichever one we prefer?

IMHO, we should follow the Dart style guide.

[eseidel, 2015-06-04 18:08:11]

I recommend following Dart style for all Dart code.  All C++ code we use
Chromium style for new files and existing Blink style for existing Blink files. 
For new C++ code which needs to interface with the IDL compiler, I recommend
Chromium style, except for functions exposed to IDL, whereby we need to follow
Blink style to match the compiler.

Does that answer the question?

[Hixie, 2015-06-04 18:10:12]

Yeah, we should follow the style guide. I'll go fix this one.
I noticed it talks about enum values being lowerCamelCase too, which I think is
a recent change? I guess I'll go through and fix those too.