[cc] Add window decoration layers (NinePatch)

[cc] Add window decoration layers (NinePatch)

This adds a new layer type for window decorations.
It uses small textures that get scaled non-uniformly (only along the side axes, while the corner quads are not scaled to allow for non-filtered rounded edges). The desired output size is derived from the layer bounds. The aperture specifies the transparent region inside the bitmap where the window contents are supposed to show.

[danakj, 2012-09-24 14:35:00]

a couple gtfo style nits for you :)

https://codereview.chromium.org/10963056/diff/1/cc/CCDecorationLayerImpl.h
File cc/CCDecorationLayerImpl.h (right):

https://codereview.chromium.org/10963056/diff/1/cc/CCDecorationLayerImpl.h#ne...
cc/CCDecorationLayerImpl.h:2: * Copyright (C) 2012 Google Inc. All rights
reserved.
nit: switch to the chromium copyright style for new files.

https://codereview.chromium.org/10963056/diff/1/cc/DecorationLayerChromium.h
File cc/DecorationLayerChromium.h (right):

https://codereview.chromium.org/10963056/diff/1/cc/DecorationLayerChromium.h#...
cc/DecorationLayerChromium.h:35: #if USE(ACCELERATED_COMPOSITING)
nit: drop the ACCELERATED_COMPOSITING in new files.

https://codereview.chromium.org/10963056/diff/1/webkit/compositor_bindings/We...
File webkit/compositor_bindings/WebDecorationLayerImpl.h (right):

https://codereview.chromium.org/10963056/diff/1/webkit/compositor_bindings/We...
webkit/compositor_bindings/WebDecorationLayerImpl.h:29: #include "SkBitmap.h"
this include seems to be unused here.

[no sievers, 2012-09-24 14:35:26]

not for review yet, but dtrain and jerome might want to start playing with it.
Also needs WebDecorationLayer.h in WebKit from
https://bug-96347-attachments.webkit.org/attachment.cgi?id=165375

[no sievers, 2012-09-24 14:37:44]

Thanks. Or since this is a new file should I convert it to chromium style
entirely?

 2012/09/24 14:35:00, danakj wrote:
> a couple gtfo style nits for you :)
> 
> https://codereview.chromium.org/10963056/diff/1/cc/CCDecorationLayerImpl.h
> File cc/CCDecorationLayerImpl.h (right):
> 
>
https://codereview.chromium.org/10963056/diff/1/cc/CCDecorationLayerImpl.h#ne...
> cc/CCDecorationLayerImpl.h:2: * Copyright (C) 2012 Google Inc. All rights
> reserved.
> nit: switch to the chromium copyright style for new files.
> 
> https://codereview.chromium.org/10963056/diff/1/cc/DecorationLayerChromium.h
> File cc/DecorationLayerChromium.h (right):
> 
>
https://codereview.chromium.org/10963056/diff/1/cc/DecorationLayerChromium.h#...
> cc/DecorationLayerChromium.h:35: #if USE(ACCELERATED_COMPOSITING)
> nit: drop the ACCELERATED_COMPOSITING in new files.
> 
>
https://codereview.chromium.org/10963056/diff/1/webkit/compositor_bindings/We...
> File webkit/compositor_bindings/WebDecorationLayerImpl.h (right):
> 
>
https://codereview.chromium.org/10963056/diff/1/webkit/compositor_bindings/We...
> webkit/compositor_bindings/WebDecorationLayerImpl.h:29: #include "SkBitmap.h"
> this include seems to be unused here.

[no sievers, 2012-09-24 14:43:40]

Jerome, David,

the way this works is that you can use setBounds() to size the layer without
scaling the four edge quads. You would want to make the decoration layer a
sibling of the window content layer. I.e put a transform on the window content
layer to scale it and adjust the deco layer bounds accordingly.
If you want to uniformly scale the deco layer, just put a transform on that
layer or a parent.
Also, you want to position it correctly, relative to the window origin, and set
the anchor point accordingly. I *think* this will let you do what you need, but
there's only one way to find out :)

    decoLayer->setBitmap(bitmap, IntRect(10, 10, 100, 100));
    decoLayer->setIsDrawable(true);
    decoLayer->setBounds(IntSize(120, 120)); // non-uniform scale
    decoLayer->setPosition(FloatPoint(-10, -10)); // position relative to parent
    WebTransformationMatrix transform;
    transform.scale(4.0); // uniform draw scale
    decoLayer->setAnchorPoint(FloatPoint());
    decoLayer->setTransform(transform);

[jscholler, 2012-09-24 14:47:37]

Thanks!

Jerome

On Mon, Sep 24, 2012 at 7:43 AM, <sievers@chromium.org> wrote:

> Jerome, David,
>
> the way this works is that you can use setBounds() to size the layer
> without
> scaling the four edge quads. You would want to make the decoration layer a
> sibling of the window content layer. I.e put a transform on the window
> content
> layer to scale it and adjust the deco layer bounds accordingly.
> If you want to uniformly scale the deco layer, just put a transform on that
> layer or a parent.
> Also, you want to position it correctly, relative to the window origin,
> and set
> the anchor point accordingly. I *think* this will let you do what you
> need, but
> there's only one way to find out :)
>
>     decoLayer->setBitmap(bitmap, IntRect(10, 10, 100, 100));
>     decoLayer->setIsDrawable(true)**;
>     decoLayer->setBounds(IntSize(**120, 120)); // non-uniform scale
>     decoLayer->setPosition(**FloatPoint(-10, -10)); // position relative
> to parent
>     WebTransformationMatrix transform;
>     transform.scale(4.0); // uniform draw scale
>     decoLayer->setAnchorPoint(**FloatPoint());
>     decoLayer->setTransform(**transform);
>
>
https://codereview.chromium.**org/10963056/<https://codereview.chromium.org/1...
>

[danakj, 2012-09-24 14:50:06]

On 2012/09/24 14:37:44, Daniel Sievers wrote:
> Thanks. Or since this is a new file should I convert it to chromium style
> entirely?

We don't have replacement data types for gtfo yet, so it would be a weird mix of
the two, so IMO no. The copyright/ifdef are the changes that we have made in
other files so far.

[no sievers, 2012-10-11 20:12:47]

Ok, I've picked this up again as it seems like this is needed urgently now :)

I've rebased and added some tests. Not really happy with what was necessary in
DecorationLayerChromiumTest.cpp to test the upload logic.

Alex prefers the name NinePatch over DecorationLayer, so I'm taking suggestions
for names.

[jamesr, 2012-10-11 20:14:46]

Why do you need a custom layer type instead of layers for the distinct elements?

[enne (OOO), 2012-10-11 20:18:11]

I was really hoping that we could have a single decoration manager per
compositor to handle these sorts of shared bitmap resources, rather than having
a specific layer type that can't share them.

[no sievers, 2012-10-11 20:19:50]

We wanted this to reduce the complexity of creating a decoration from the app as
well as the number of layers being created. Also, I think we want this not to
use tiles. Finally, we can also then go ahead and handle these textures in a
special way (UI priority and later potentially sharing textures across layers).


On 2012/10/11 20:14:46, jamesr wrote:
> Why do you need a custom layer type instead of layers for the distinct
elements?

[no sievers, 2012-10-11 20:20:58]

Sharing would be nice, but isn't that somewhat orthogonal?
I was imagining that we can later change DecorationLayerChromium to just get a
shared texture if one is available.

On 2012/10/11 20:18:11, enne wrote:
> I was really hoping that we could have a single decoration manager per
> compositor to handle these sorts of shared bitmap resources, rather than
having
> a specific layer type that can't share them.

[jamesr, 2012-10-11 20:21:37]

There are two issues: how to handle the resources and how to position the final.
 I think for the latter we don't really need new layer types - the caller can
just make the layers they need and put them wherever is needed.  I don't think
the compositor needs special knowledge of 9-boxes.

For the former, we need a way to say "hey I want to refer to this resource" and
have that be shared.

[Jerome, 2012-10-11 20:47:07]

With our current design we would easily go over a thousand layers. It needs to
run at 60 fps on top of a live webpage on a phone. Introducing the 9-boxes layer
was a simple way to keep the layer count in the hundreds.
Resources sharing is more a nice to have rather than a must have because the
resources are usually smaller than 100*100 pixels.

[jamesr, 2012-10-11 21:43:58]

On 2012/10/11 20:12:47, Daniel Sievers wrote:
> Ok, I've picked this up again as it seems like this is needed urgently now :)
> 
> I've rebased and added some tests. Not really happy with what was necessary in
> DecorationLayerChromiumTest.cpp to test the upload logic.

I think this is pretty similar to ImageLayerChromium's LayerTextureUpdater.  You
might be able to refactor that into a common location.

> 
> Alex prefers the name NinePatch over DecorationLayer, so I'm taking
suggestions
> for names.