New Composite CSS border object

I am proposing this new composite object as a way of removing a lot of horrible geometry generation from Blink and deferring the decisions to Skia where we can presumably do a better job.

[reed1, 2013-11-25 21:21:52]

Waiting to see the compelling examples where "core" knowledge is needed to do a
better job.

For now, can we land this in src/chromeutils/* ?

[robertphillips, 2013-11-26 15:00:38]

For raster this won't necessarily improve things. For GPU is could help a lot.
The two main cases in which this would help are:

1) round rects or rects drawn with an inset box shadow (i.e., theverge)
2) round rects or rects drawn with a border (i.e., worldjournal)

The first case is currently achieved in Blink via the creation of a nested
(r)rectorii which is then blurred and then has its center clipped out.
Independent of this CL, this could be resolved to switching to an inner blur.

The second case manifests in two ways:

Lots of little fiddly intersecting clips when the border isn't homogeneous (2a)
and large nested (r)rectorii when it is (2b). In the former case, Ganesh will
drop back to raster because the clips are almost always combinations of AA and
non-AA, in the latter case Ganesh drops back to raster to render the large
concave path.

For (1), we want to have an analytic solution as in the raster case. This could
be achieved by detecting the inner blurred (r)rect just as raster does.

For (2a), we want to just generate the geometry (if possible) or be able to draw
quarters of round rects.

For (2b), we want to know we just have to draw a nested (r)rrect and just do so
(rather then drawing a concave path). This could also be achieved by examining
the path (expensive) or storing the contour information as the path is generated
(controversial).

[robertphillips, 2013-12-09 15:17:28]

PTAL

[bsalomon, 2013-12-09 16:19:53]

https://codereview.chromium.org/86263003/diff/60001/experimental/ChromeUtils/...
File experimental/ChromeUtils/SkBorder.h (right):

https://codereview.chromium.org/86263003/diff/60001/experimental/ChromeUtils/...
experimental/ChromeUtils/SkBorder.h:23: */
I'm wondering if we want to bite all of these off at once (or duplicate all the
Blink code to fallback to a series of draws). Maybe we could start small and
grow this? Though, I also don't know how SkBorder would be used in Blink so this
comment may be off the mark.

[robertphillips, 2013-12-09 16:25:56]

https://codereview.chromium.org/86263003/diff/60001/experimental/ChromeUtils/...
File experimental/ChromeUtils/SkBorder.h (right):

https://codereview.chromium.org/86263003/diff/60001/experimental/ChromeUtils/...
experimental/ChromeUtils/SkBorder.h:23: */
My plan was to initially duplicate all the Blink code & allow Blink to be
switched (at compile time) to their code path vs. ours and then slowly
refactor/improve the borrowed code.

[bsalomon, 2013-12-09 18:25:41]

On 2013/12/09 16:25:56, robertphillips wrote:
>
https://codereview.chromium.org/86263003/diff/60001/experimental/ChromeUtils/...
> File experimental/ChromeUtils/SkBorder.h (right):
> 
>
https://codereview.chromium.org/86263003/diff/60001/experimental/ChromeUtils/...
> experimental/ChromeUtils/SkBorder.h:23: */
> My plan was to initially duplicate all the Blink code & allow Blink to be
> switched (at compile time) to their code path vs. ours and then slowly
> refactor/improve the borrowed code.

As long as you feel like we can back away from supporting all that stuff in
Skia, then lgtm.

[robertphillips, 2013-12-10 17:46:44]

committed as r12597