[SPv2] Support composited plugins via foreign layers.

[SPv2] Support composited plugins via foreign layers.

BUG=587970
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/bf29b13a060e17f0e1cf96886ab1c798f7d54cc8
Cr-Commit-Position: refs/heads/master@{#378117}

Committed: https://crrev.com/c5a5aaba0445bf16820fdf0a5e0093f98e06dd23
Cr-Commit-Position: refs/heads/master@{#378148}

Committed: https://crrev.com/8b3ed673a5787b3cc14a2a8cc8de7380cb4c1d88
Cr-Commit-Position: refs/heads/master@{#378586}

[jbroman, 2016-02-22 16:29:09]

Description was changed from

==========
[SPv2] Support composited plugins via foreign layers.

BUG=587970
==========

to

==========
[SPv2] Support composited plugins via foreign layers.

BUG=587970
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[jbroman, 2016-02-22 17:52:45]

[email protected] changed reviewers:
+ [email protected], [email protected]

[jbroman, 2016-02-22 17:52:46]

This is probably on the large side for a CL, but a bunch of it is boilerplate,
so I figured I'd try it as one CL. I can split it if you'd like.

[pdr., 2016-02-23 05:47:05]

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.cpp
(right):

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.cpp:59:
#ifndef NDEBUG
Too many newlines! Think of the bytes.

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h
(right):

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h:22:
// Represents foreign content (produced outside Blink) which draws to a layer.
Having cc::layers this far up the pipeline seems like it could cause issues in
terms of layer management. Can you expand on the overall design of this patch a
bit? For example, when a plugin goes away, do we need to wait for paint to
release the last cc:layer ref?

I view the high-level spv2 design as:
layout -> paint props -> paint -> [unknown blink->cc step that solves all the
world's problems] -> cc layer management.

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h:28:
class PLATFORM_EXPORT ForeignLayerDisplayItem final : public DisplayItem {
Would canvas and video use this class too?

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h:30:
ForeignLayerDisplayItem(
The display items in spv2 are currently all drawings which has some benefits in
terms of complexity.

Another approach to the foreign layer problem would be to create
ForeignPaintChunk which has no display items and holds a ref the foreign data.
This more closely mirrors the existing code and avoids needing to consider
foreign layers in the display item cache / merge logic. I suspect we'll need to
avoid squashing paint chunks with foreign content as well, which will be easier
if we just have special chunks.

WDYT?

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/web/WebPluginContainerImpl.cpp (right):

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/web/WebPluginContainerImpl.cpp:130:
recordForeignLayer(
Can you help me understand how this works at a high level? We're early outing
here before the paint code below runs--is that just not needed?

[jbroman, 2016-02-23 18:43:50]

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.cpp
(right):

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.cpp:59:
#ifndef NDEBUG
On 2016/02/23 at 05:47:05, pdr wrote:
> Too many newlines! Think of the bytes.

If you insist.

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h
(right):

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h:22:
// Represents foreign content (produced outside Blink) which draws to a layer.
On 2016/02/23 at 05:47:05, pdr wrote:
> Having cc::layers this far up the pipeline seems like it could cause issues in
terms of layer management. Can you expand on the overall design of this patch a
bit? For example, when a plugin goes away, do we need to wait for paint to
release the last cc:layer ref?

Yes, but we already needed to do that. The layer also has an owning reference in
the layer tree, and can't die until the layer tree is updated (which is done
after paint).

> I view the high-level spv2 design as:
> layout -> paint props -> paint -> [unknown blink->cc step that solves all the
world's problems] -> cc layer management.

Except that not _everything_ is laid out and painted by Blink like that. This
allows things that aren't, like composited plugins, to enter the composited
pipeline.

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h:28:
class PLATFORM_EXPORT ForeignLayerDisplayItem final : public DisplayItem {
On 2016/02/23 at 05:47:05, pdr wrote:
> Would canvas and video use this class too?

I imagine them working similarly, yes. If they don't have layers created
already, we might consider instead having a display list that has enough info to
build a layer, but I'm not sure that's actually easier.

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h:30:
ForeignLayerDisplayItem(
On 2016/02/23 at 05:47:05, pdr wrote:
> The display items in spv2 are currently all drawings which has some benefits
in terms of complexity.
> 
> Another approach to the foreign layer problem would be to create
ForeignPaintChunk which has no display items and holds a ref the foreign data.

core/ doesn't know much about paint chunks. You could do something like that,
but I think it's more complicated. I don't think there's anything in this CL
really complicates the logic for dealing with drawings.

> This more closely mirrors the existing code and avoids needing to consider
foreign layers in the display item cache / merge logic.

They're already mostly ignored, since that logic operates only on drawings.

> I suspect we'll need to avoid squashing paint chunks with foreign content as
well, which will be easier if we just have special chunks.

Yes, we will. There will be a number of reasons that things cannot be squashed,
of which this is one. I don't object to having a bit to say "I'm unsquashable"
on the PaintChunk when we get to that.

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/web/WebPluginContainerImpl.cpp (right):

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/web/WebPluginContainerImpl.cpp:130:
recordForeignLayer(
On 2016/02/23 at 05:47:05, pdr wrote:
> Can you help me understand how this works at a high level? We're early outing
here before the paint code below runs--is that just not needed?

Right. Either a WebPlugin paints through WebPlugin::paint (to an SkCanvas), or
it supports compositing, in which case it provides its WebPluginContainer with a
WebLayer.

Pre-SPv2, this worked because we created a composited layer for the
corresponding LayoutObject, and paint doesn't proceed into composited layers (it
assumes the compositor will paint them if necessary).

[pdr., 2016-02-23 21:20:31]

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h
(right):

https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h:30:
ForeignLayerDisplayItem(
On 2016/02/23 at 18:43:50, jbroman wrote:
> On 2016/02/23 at 05:47:05, pdr wrote:
> > The display items in spv2 are currently all drawings which has some benefits
in terms of complexity.
> > 
> > Another approach to the foreign layer problem would be to create
ForeignPaintChunk which has no display items and holds a ref the foreign data.
> 
> core/ doesn't know much about paint chunks. You could do something like that,
but I think it's more complicated. I don't think there's anything in this CL
really complicates the logic for dealing with drawings.
> 
> > This more closely mirrors the existing code and avoids needing to consider
foreign layers in the display item cache / merge logic.
> 
> They're already mostly ignored, since that logic operates only on drawings.
> 
> > I suspect we'll need to avoid squashing paint chunks with foreign content as
well, which will be easier if we just have special chunks.
> 
> Yes, we will. There will be a number of reasons that things cannot be
squashed, of which this is one. I don't object to having a bit to say "I'm
unsquashable" on the PaintChunk when we get to that.

I still think switching to paint chunks would be a better design. My biggest
complaint is that a layer doesn't follow the semantics of a display item in spv2
in terms of drawing, caching, invalidation, etc. A paint chunk approach doesn't
need to teach core about paint chunks, you'd just recordForeignLayer produce a
chunk behind the scenes instead of a chunk containing a single display item.

[jbroman, 2016-02-23 21:28:44]

On 2016/02/23 at 21:20:31, pdr wrote:
>
https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
> File
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h
(right):
> 
>
https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
>
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h:30:
ForeignLayerDisplayItem(
> On 2016/02/23 at 18:43:50, jbroman wrote:
> > On 2016/02/23 at 05:47:05, pdr wrote:
> > > The display items in spv2 are currently all drawings which has some
benefits in terms of complexity.
> > > 
> > > Another approach to the foreign layer problem would be to create
ForeignPaintChunk which has no display items and holds a ref the foreign data.
> > 
> > core/ doesn't know much about paint chunks. You could do something like
that, but I think it's more complicated. I don't think there's anything in this
CL really complicates the logic for dealing with drawings.
> > 
> > > This more closely mirrors the existing code and avoids needing to consider
foreign layers in the display item cache / merge logic.
> > 
> > They're already mostly ignored, since that logic operates only on drawings.
> > 
> > > I suspect we'll need to avoid squashing paint chunks with foreign content
as well, which will be easier if we just have special chunks.
> > 
> > Yes, we will. There will be a number of reasons that things cannot be
squashed, of which this is one. I don't object to having a bit to say "I'm
unsquashable" on the PaintChunk when we get to that.
> 
> I still think switching to paint chunks would be a better design. My biggest
complaint is that a layer doesn't follow the semantics of a display item in spv2
in terms of drawing, caching, invalidation, etc. A paint chunk approach doesn't
need to teach core about paint chunks, you'd just recordForeignLayer produce a
chunk behind the scenes instead of a chunk containing a single display item.

Which semantics does it not follow? It isn't a drawing (so it doesn't need to go
through the SkPicture caching magic), but it behaves like every other display
item.

I think if you try to make it a magical paint chunk, it will confuse the various
bits of logic we have to remove "empty" begin/end display item pairs and such.
Doesn't matter much in a post-SPv2 world, though it might trigger assertions.

I quite like the display list being the complete stacking list of content (3D
sorting notwithstanding). I'm not totally wedded to it, but I'd like to better
understand your objections.

[pdr., 2016-02-23 22:03:32]

On 2016/02/23 at 21:28:44, jbroman wrote:
> On 2016/02/23 at 21:20:31, pdr wrote:
> >
https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
> > File
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h
(right):
> > 
> >
https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
> >
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h:30:
ForeignLayerDisplayItem(
> > On 2016/02/23 at 18:43:50, jbroman wrote:
> > > On 2016/02/23 at 05:47:05, pdr wrote:
> > > > The display items in spv2 are currently all drawings which has some
benefits in terms of complexity.
> > > > 
> > > > Another approach to the foreign layer problem would be to create
ForeignPaintChunk which has no display items and holds a ref the foreign data.
> > > 
> > > core/ doesn't know much about paint chunks. You could do something like
that, but I think it's more complicated. I don't think there's anything in this
CL really complicates the logic for dealing with drawings.
> > > 
> > > > This more closely mirrors the existing code and avoids needing to
consider foreign layers in the display item cache / merge logic.
> > > 
> > > They're already mostly ignored, since that logic operates only on
drawings.
> > > 
> > > > I suspect we'll need to avoid squashing paint chunks with foreign
content as well, which will be easier if we just have special chunks.
> > > 
> > > Yes, we will. There will be a number of reasons that things cannot be
squashed, of which this is one. I don't object to having a bit to say "I'm
unsquashable" on the PaintChunk when we get to that.
> > 
> > I still think switching to paint chunks would be a better design. My biggest
complaint is that a layer doesn't follow the semantics of a display item in spv2
in terms of drawing, caching, invalidation, etc. A paint chunk approach doesn't
need to teach core about paint chunks, you'd just recordForeignLayer produce a
chunk behind the scenes instead of a chunk containing a single display item.
> 
> Which semantics does it not follow? It isn't a drawing (so it doesn't need to
go through the SkPicture caching magic), but it behaves like every other display
item.

I'm hoping that in spv2, the only display items are drawing display items. With
this patch we would have:
DrawingDisplayItem
CachedDrawingDisplayItem
ForeignLayerDisplayItem

One of these seems out of place :)

Because foreign layers are always composited, there will never be a sequence
like:
DrawingDisplayItem, ForeignLayerDisplayItem, DrawingDisplayItem
There's just never a reason for ForeignLayerDisplayItem and DrawingDisplayItem
to mix, which is why I don't think they belong together. The whole merge and
cacheability logic in DisplayItemList isn't used for ForeignLayerDisplayItem,
nor are most of the members on DisplayItem.

> 
> I think if you try to make it a magical paint chunk, it will confuse the
various bits of logic we have to remove "empty" begin/end display item pairs and
such. Doesn't matter much in a post-SPv2 world, though it might trigger
assertions.

I'm thinking of having two types of chunks:
PaintChunk, for painting, which contains a display list.
ForeignLayerChunk, for foreign layers, which contains a pointer to a foreign
layer.

This way there is no need to handle the begin/end business since there is no
display list (or, it's always empty, depending on how the inheritance is setup).

> 
> I quite like the display list being the complete stacking list of content (3D
sorting notwithstanding). I'm not totally wedded to it, but I'd like to better
understand your objections.

Does my latest reply help explain my point more? There are issues with both
approaches so I don't mean to put my foot down on this patch--I'd just like to
compare the two approaches since ForeignLayerChunk seems to have fewer
downsides.

[jbroman, 2016-02-23 22:18:03]

On 2016/02/23 at 22:03:32, pdr wrote:
> On 2016/02/23 at 21:28:44, jbroman wrote:
> > On 2016/02/23 at 21:20:31, pdr wrote:
> > >
https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
> > > File
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h
(right):
> > > 
> > >
https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
> > >
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h:30:
ForeignLayerDisplayItem(
> > > On 2016/02/23 at 18:43:50, jbroman wrote:
> > > > On 2016/02/23 at 05:47:05, pdr wrote:
> > > > > The display items in spv2 are currently all drawings which has some
benefits in terms of complexity.
> > > > > 
> > > > > Another approach to the foreign layer problem would be to create
ForeignPaintChunk which has no display items and holds a ref the foreign data.
> > > > 
> > > > core/ doesn't know much about paint chunks. You could do something like
that, but I think it's more complicated. I don't think there's anything in this
CL really complicates the logic for dealing with drawings.
> > > > 
> > > > > This more closely mirrors the existing code and avoids needing to
consider foreign layers in the display item cache / merge logic.
> > > > 
> > > > They're already mostly ignored, since that logic operates only on
drawings.
> > > > 
> > > > > I suspect we'll need to avoid squashing paint chunks with foreign
content as well, which will be easier if we just have special chunks.
> > > > 
> > > > Yes, we will. There will be a number of reasons that things cannot be
squashed, of which this is one. I don't object to having a bit to say "I'm
unsquashable" on the PaintChunk when we get to that.
> > > 
> > > I still think switching to paint chunks would be a better design. My
biggest complaint is that a layer doesn't follow the semantics of a display item
in spv2 in terms of drawing, caching, invalidation, etc. A paint chunk approach
doesn't need to teach core about paint chunks, you'd just recordForeignLayer
produce a chunk behind the scenes instead of a chunk containing a single display
item.
> > 
> > Which semantics does it not follow? It isn't a drawing (so it doesn't need
to go through the SkPicture caching magic), but it behaves like every other
display item.
> 
> I'm hoping that in spv2, the only display items are drawing display items.
With this patch we would have:
> DrawingDisplayItem
> CachedDrawingDisplayItem
> ForeignLayerDisplayItem
> 
> One of these seems out of place :)

Yes, CachedDrawingDisplayItem is just a placeholder and not actual content. :D

> Because foreign layers are always composited, there will never be a sequence
like:
> DrawingDisplayItem, ForeignLayerDisplayItem, DrawingDisplayItem
> There's just never a reason for ForeignLayerDisplayItem and DrawingDisplayItem
to mix, which is why I don't think they belong together. The whole merge and
cacheability logic in DisplayItemList isn't used for ForeignLayerDisplayItem,
nor are most of the members on DisplayItem.
> 
> > 
> > I think if you try to make it a magical paint chunk, it will confuse the
various bits of logic we have to remove "empty" begin/end display item pairs and
such. Doesn't matter much in a post-SPv2 world, though it might trigger
assertions.
> 
> I'm thinking of having two types of chunks:
> PaintChunk, for painting, which contains a display list.
> ForeignLayerChunk, for foreign layers, which contains a pointer to a foreign
layer.

These are concrete and non-virtual right now. The overhead of doing
Vector<OwnPtr<Chunk>> or ContiguousContainer<Chunk> seems really unfortunate.

I think I'd actually implement this as a single class with a discriminator enum.

(DisplayItem, OTOH, is already heterogenous.)

> This way there is no need to handle the begin/end business since there is no
display list (or, it's always empty, depending on how the inheritance is setup).
> 
> > 
> > I quite like the display list being the complete stacking list of content
(3D sorting notwithstanding). I'm not totally wedded to it, but I'd like to
better understand your objections.
> 
> Does my latest reply help explain my point more? There are issues with both
approaches so I don't mean to put my foot down on this patch--I'd just like to
compare the two approaches since ForeignLayerChunk seems to have fewer
downsides.

It's not unreasonable. It would be a little regrettable to add a totally
separate method to PaintController for this that has to be interleaved with the
commitNewDisplayItems etc., but is special. But there's no serious problems with
either approach, I think.

[trchen, 2016-02-23 22:36:05]

On 2016/02/23 22:18:03, jbroman wrote:
> On 2016/02/23 at 22:03:32, pdr wrote:
> > On 2016/02/23 at 21:28:44, jbroman wrote:
> > > On 2016/02/23 at 21:20:31, pdr wrote:
> > > >
>
https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
> > > > File
> third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h
> (right):
> > > > 
> > > >
>
https://codereview.chromium.org/1714153002/diff/100001/third_party/WebKit/Sou...
> > > >
>
third_party/WebKit/Source/platform/graphics/paint/ForeignLayerDisplayItem.h:30:
> ForeignLayerDisplayItem(
> > > > On 2016/02/23 at 18:43:50, jbroman wrote:
> > > > > On 2016/02/23 at 05:47:05, pdr wrote:
> > > > > > The display items in spv2 are currently all drawings which has some
> benefits in terms of complexity.
> > > > > > 
> > > > > > Another approach to the foreign layer problem would be to create
> ForeignPaintChunk which has no display items and holds a ref the foreign data.
> > > > > 
> > > > > core/ doesn't know much about paint chunks. You could do something
like
> that, but I think it's more complicated. I don't think there's anything in
this
> CL really complicates the logic for dealing with drawings.
> > > > > 
> > > > > > This more closely mirrors the existing code and avoids needing to
> consider foreign layers in the display item cache / merge logic.
> > > > > 
> > > > > They're already mostly ignored, since that logic operates only on
> drawings.
> > > > > 
> > > > > > I suspect we'll need to avoid squashing paint chunks with foreign
> content as well, which will be easier if we just have special chunks.
> > > > > 
> > > > > Yes, we will. There will be a number of reasons that things cannot be
> squashed, of which this is one. I don't object to having a bit to say "I'm
> unsquashable" on the PaintChunk when we get to that.
> > > > 
> > > > I still think switching to paint chunks would be a better design. My
> biggest complaint is that a layer doesn't follow the semantics of a display
item
> in spv2 in terms of drawing, caching, invalidation, etc. A paint chunk
approach
> doesn't need to teach core about paint chunks, you'd just recordForeignLayer
> produce a chunk behind the scenes instead of a chunk containing a single
display
> item.
> > > 
> > > Which semantics does it not follow? It isn't a drawing (so it doesn't need
> to go through the SkPicture caching magic), but it behaves like every other
> display item.
> > 
> > I'm hoping that in spv2, the only display items are drawing display items.
> With this patch we would have:
> > DrawingDisplayItem
> > CachedDrawingDisplayItem
> > ForeignLayerDisplayItem
> > 
> > One of these seems out of place :)
> 
> Yes, CachedDrawingDisplayItem is just a placeholder and not actual content. :D
> 
> > Because foreign layers are always composited, there will never be a sequence
> like:
> > DrawingDisplayItem, ForeignLayerDisplayItem, DrawingDisplayItem
> > There's just never a reason for ForeignLayerDisplayItem and
DrawingDisplayItem
> to mix, which is why I don't think they belong together. The whole merge and
> cacheability logic in DisplayItemList isn't used for ForeignLayerDisplayItem,
> nor are most of the members on DisplayItem.
> > 
> > > 
> > > I think if you try to make it a magical paint chunk, it will confuse the
> various bits of logic we have to remove "empty" begin/end display item pairs
and
> such. Doesn't matter much in a post-SPv2 world, though it might trigger
> assertions.
> > 
> > I'm thinking of having two types of chunks:
> > PaintChunk, for painting, which contains a display list.
> > ForeignLayerChunk, for foreign layers, which contains a pointer to a foreign
> layer.
> 
> These are concrete and non-virtual right now. The overhead of doing
> Vector<OwnPtr<Chunk>> or ContiguousContainer<Chunk> seems really unfortunate.
> 
> I think I'd actually implement this as a single class with a discriminator
enum.
> 
> (DisplayItem, OTOH, is already heterogenous.)
> 
> > This way there is no need to handle the begin/end business since there is no
> display list (or, it's always empty, depending on how the inheritance is
setup).
> > 
> > > 
> > > I quite like the display list being the complete stacking list of content
> (3D sorting notwithstanding). I'm not totally wedded to it, but I'd like to
> better understand your objections.
> > 
> > Does my latest reply help explain my point more? There are issues with both
> approaches so I don't mean to put my foot down on this patch--I'd just like to
> compare the two approaches since ForeignLayerChunk seems to have fewer
> downsides.
> 
> It's not unreasonable. It would be a little regrettable to add a totally
> separate method to PaintController for this that has to be interleaved with
the
> commitNewDisplayItems etc., but is special. But there's no serious problems
with
> either approach, I think.

I was almost convinced by pdr that the foreign layer should be a special paint
chunk. :p

But how will it interact with subsequence cache? Although I imagine subsequence
cache will need a lot of change for SPv2 but it currently works at display item
level. How could it insert the special paint chunk at the right place if there
is no display item placeholder for it? Unless we have a new subsequence cache
implementation that works at paint chunk level, I think we need to have a
special display item.

[pdr., 2016-02-23 22:52:52]

On 2016/02/23 at 22:36:05, trchen wrote:
> But how will it interact with subsequence cache? Although I imagine
subsequence cache will need a lot of change for SPv2 but it currently works at
display item level. How could it insert the special paint chunk at the right
place if there is no display item placeholder for it? Unless we have a new
subsequence cache implementation that works at paint chunk level, I think we
need to have a special display item.

That's a good point.

grumble grumble... we still don't have a good enough design for the blink paint
chunk -> cc layer step which would let us answer this... grumble :(

I'm unsure how this will work. @Jbroman, curious about your thoughts on this
advantage of the display item approach.

[jbroman, 2016-02-25 15:34:52]

On 2016/02/23 at 22:52:52, pdr wrote:
> On 2016/02/23 at 22:36:05, trchen wrote:
> > But how will it interact with subsequence cache? Although I imagine
subsequence cache will need a lot of change for SPv2 but it currently works at
display item level. How could it insert the special paint chunk at the right
place if there is no display item placeholder for it? Unless we have a new
subsequence cache implementation that works at paint chunk level, I think we
need to have a special display item.
> 
> That's a good point.
> 
> grumble grumble... we still don't have a good enough design for the blink
paint chunk -> cc layer step which would let us answer this... grumble :(
> 
> I'm unsure how this will work. @Jbroman, curious about your thoughts on this
advantage of the display item approach.

I think it's a good point; you could have separate subsequence caches for
drawings and foreign layers, but that seems like needless duplication. Maybe
there would be a way to implement subsequence caching in terms of chunks, but I
don't think it's a trivial mapping.

I'm not sure I understand how the chunk -> layer process is the issue here,
though.

[jbroman, 2016-02-25 15:56:20]

Oh, but if we want to continue to use subsequence caching, it will need to be
adapted to know some things about paint chunks, at least, because right now when
it copies display items out of its cache, it does _not_ restore the
corresponding paint chunk properties.

[pdr., 2016-02-25 22:00:52]

Jeremy found that the foreign chunk approach is more complex than originally
thought. That complexity + the replies in this review have convinced me that
this is a good approach for now.

https://codereview.chromium.org/1714153002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/graphics/paint/PaintChunker.h (right):

https://codereview.chromium.org/1714153002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/paint/PaintChunker.h:40: void
incrementDisplayItemIndex(ItemBehavior = DefaultBehavior);
Nit: I think it'll be safer to make the callsites be explicit here instead of
offering a default.

https://codereview.chromium.org/1714153002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/graphics/paint/PaintController.cpp
(right):

https://codereview.chromium.org/1714153002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/paint/PaintController.cpp:100:
m_newPaintChunks.incrementDisplayItemIndex(behaviorOfItemType(displayItem.type()));
We'll need to have a bit on the paint chunk for whether it contains a foreign
layer (e.g., to prevent squashing, etc). If we add that bit to the paint chunk
properties, the behavior of creating a new paint chunk will fall out naturally
without needing behaviorOfItemType. WDYT of something like that?

[jbroman, 2016-02-26 16:07:31]

https://codereview.chromium.org/1714153002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/graphics/paint/PaintChunker.h (right):

https://codereview.chromium.org/1714153002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/paint/PaintChunker.h:40: void
incrementDisplayItemIndex(ItemBehavior = DefaultBehavior);
On 2016/02/25 at 22:00:52, pdr wrote:
> Nit: I think it'll be safer to make the callsites be explicit here instead of
offering a default.

Done.

https://codereview.chromium.org/1714153002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/graphics/paint/PaintController.cpp
(right):

https://codereview.chromium.org/1714153002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/paint/PaintController.cpp:100:
m_newPaintChunks.incrementDisplayItemIndex(behaviorOfItemType(displayItem.type()));
On 2016/02/25 at 22:00:52, pdr wrote:
> We'll need to have a bit on the paint chunk for whether it contains a foreign
layer (e.g., to prevent squashing, etc). If we add that bit to the paint chunk
properties, the behavior of creating a new paint chunk will fall out naturally
without needing behaviorOfItemType.

Well, no, we'd still need logic because two adjacent foreign layers also cannot
be combined into one paint chunk.

> WDYT of something like that?

Not objectionable, though in light of the above I'm not sure whether it's
better.

[pdr., 2016-02-26 16:12:48]

On 2016/02/26 at 16:07:31, jbroman wrote:
>
https://codereview.chromium.org/1714153002/diff/140001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/platform/graphics/paint/PaintChunker.h (right):
> 
>
https://codereview.chromium.org/1714153002/diff/140001/third_party/WebKit/Sou...
> third_party/WebKit/Source/platform/graphics/paint/PaintChunker.h:40: void
incrementDisplayItemIndex(ItemBehavior = DefaultBehavior);
> On 2016/02/25 at 22:00:52, pdr wrote:
> > Nit: I think it'll be safer to make the callsites be explicit here instead
of offering a default.
> 
> Done.
> 
>
https://codereview.chromium.org/1714153002/diff/140001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/platform/graphics/paint/PaintController.cpp
(right):
> 
>
https://codereview.chromium.org/1714153002/diff/140001/third_party/WebKit/Sou...
> third_party/WebKit/Source/platform/graphics/paint/PaintController.cpp:100:
m_newPaintChunks.incrementDisplayItemIndex(behaviorOfItemType(displayItem.type()));
> On 2016/02/25 at 22:00:52, pdr wrote:
> > We'll need to have a bit on the paint chunk for whether it contains a
foreign layer (e.g., to prevent squashing, etc). If we add that bit to the paint
chunk properties, the behavior of creating a new paint chunk will fall out
naturally without needing behaviorOfItemType.
> 
> Well, no, we'd still need logic because two adjacent foreign layers also
cannot be combined into one paint chunk.
> 
> > WDYT of something like that?
> 
> Not objectionable, though in light of the above I'm not sure whether it's
better.

LGTM

[jbroman, 2016-02-26 19:02:13]

The CQ bit was checked by [email protected]

[jbroman, 2016-02-26 19:02:14]

The patchset sent to the CQ was uploaded after l-g-t-m from [email protected]
Link to the patchset: https://codereview.chromium.org/1714153002/#ps180001
(title: "fix non-oilpan build")

[commit-bot: I haz the power, 2016-02-26 19:03:31]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1714153002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1714153002/180001

[jbroman, 2016-02-26 19:13:29]

The CQ bit was unchecked by [email protected]

[jbroman, 2016-02-26 19:14:48]

[email protected] changed reviewers:
+ [email protected]

[jbroman, 2016-02-26 19:14:49]

+enne for cc/blink/

Whoops, I need a cc/blink/ owner to look at the "adding a non-const version of
'extract the cc layer' to WebLayerImpl".

[enne (OOO), 2016-02-26 23:47:13]

lgtm

[jbroman, 2016-02-27 05:12:16]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2016-02-27 05:12:22]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1714153002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1714153002/180001

[commit-bot: I haz the power, 2016-02-27 05:20:50]

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2016-02-27 05:22:18]

Description was changed from

==========
[SPv2] Support composited plugins via foreign layers.

BUG=587970
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
[SPv2] Support composited plugins via foreign layers.

BUG=587970
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/bf29b13a060e17f0e1cf96886ab1c798f7d54cc8
Cr-Commit-Position: refs/heads/master@{#378117}
==========

[commit-bot: I haz the power, 2016-02-27 05:22:20]

Patchset 10 (id:??) landed as
https://crrev.com/bf29b13a060e17f0e1cf96886ab1c798f7d54cc8
Cr-Commit-Position: refs/heads/master@{#378117}

[dcheng, 2016-02-27 05:59:27]

[email protected] changed reviewers:
+ [email protected]

[dcheng, 2016-02-27 05:59:27]

Bots are sad:
../../third_party/WebKit/Source/platform/graphics/paint/PaintController.cpp:100:83:
error: no member named 'type' in 'blink::DisplayItem'
       
m_newPaintChunks.incrementDisplayItemIndex(behaviorOfItemType(displayItem.type()));

[dcheng, 2016-02-27 05:59:36]

From
https://build.chromium.org/p/chromium.linux/buildstatus?builder=Linux%20Build...

[dcheng, 2016-02-27 05:59:52]

A revert of this CL (patchset #10 id:180001) has been created in
https://codereview.chromium.org/1738403002/ by [email protected].

The reason for reverting is: Broke the build..

[jbroman, 2016-02-27 06:00:08]

A revert of this CL (patchset #10 id:180001) has been created in
https://codereview.chromium.org/1730173009/ by [email protected].

The reason for reverting is: Broke the build:
https://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%...

This seems to have collided with another change:
https://chromium.googlesource.com/chromium/src/+/49c44c010634e2270ff761ebda34...

which renamed several methods, including DisplayItem::type.

[jbroman, 2016-02-28 00:51:46]

Relanding now, merged with master (with the DisplayItem::type ->
DisplayItem::getType rename included).

[jbroman, 2016-02-28 00:52:14]

The CQ bit was checked by [email protected]

[jbroman, 2016-02-28 00:52:15]

The patchset sent to the CQ was uploaded after l-g-t-m from [email protected],
[email protected]
Link to the patchset: https://codereview.chromium.org/1714153002/#ps200001
(title: "merge with master (DisplayItem::type rename)")

[commit-bot: I haz the power, 2016-02-28 00:52:18]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1714153002/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1714153002/200001

[commit-bot: I haz the power, 2016-02-28 02:11:12]

Committed patchset #11 (id:200001)

[commit-bot: I haz the power, 2016-02-28 02:12:20]

Description was changed from

==========
[SPv2] Support composited plugins via foreign layers.

BUG=587970
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/bf29b13a060e17f0e1cf96886ab1c798f7d54cc8
Cr-Commit-Position: refs/heads/master@{#378117}
==========

to

==========
[SPv2] Support composited plugins via foreign layers.

BUG=587970
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/bf29b13a060e17f0e1cf96886ab1c798f7d54cc8
Cr-Commit-Position: refs/heads/master@{#378117}

Committed: https://crrev.com/c5a5aaba0445bf16820fdf0a5e0093f98e06dd23
Cr-Commit-Position: refs/heads/master@{#378148}
==========

[commit-bot: I haz the power, 2016-02-28 02:12:21]

Patchset 11 (id:??) landed as
https://crrev.com/c5a5aaba0445bf16820fdf0a5e0093f98e06dd23
Cr-Commit-Position: refs/heads/master@{#378148}

[nektarios, 2016-02-29 18:27:40]

A revert of this CL (patchset #11 id:200001) has been created in
https://codereview.chromium.org/1746873002/ by [email protected].

The reason for reverting is: webkit_unit_tests on Mac-10.9
.

[jbroman, 2016-03-01 19:12:39]

On 2016/02/29 at 18:27:40, nektar wrote:
> A revert of this CL (patchset #11 id:200001) has been created in
https://codereview.chromium.org/1746873002/ by [email protected].
> 
> The reason for reverting is: webkit_unit_tests on Mac-10.9
> .

nektar (sheriff) says it's OK to reland, so kindly asking the CQ to go again.

[jbroman, 2016-03-01 19:12:45]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2016-03-01 19:13:09]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1714153002/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1714153002/200001

[commit-bot: I haz the power, 2016-03-01 21:11:00]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2016-03-01 21:11:01]

Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[jbroman, 2016-03-01 21:11:56]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2016-03-01 21:13:03]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1714153002/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1714153002/200001

[commit-bot: I haz the power, 2016-03-01 22:51:46]

Committed patchset #11 (id:200001)

[commit-bot: I haz the power, 2016-03-01 22:53:41]

Description was changed from

==========
[SPv2] Support composited plugins via foreign layers.

BUG=587970
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/bf29b13a060e17f0e1cf96886ab1c798f7d54cc8
Cr-Commit-Position: refs/heads/master@{#378117}

Committed: https://crrev.com/c5a5aaba0445bf16820fdf0a5e0093f98e06dd23
Cr-Commit-Position: refs/heads/master@{#378148}
==========

to

==========
[SPv2] Support composited plugins via foreign layers.

BUG=587970
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/bf29b13a060e17f0e1cf96886ab1c798f7d54cc8
Cr-Commit-Position: refs/heads/master@{#378117}

Committed: https://crrev.com/c5a5aaba0445bf16820fdf0a5e0093f98e06dd23
Cr-Commit-Position: refs/heads/master@{#378148}

Committed: https://crrev.com/8b3ed673a5787b3cc14a2a8cc8de7380cb4c1d88
Cr-Commit-Position: refs/heads/master@{#378586}
==========

[commit-bot: I haz the power, 2016-03-01 22:53:43]

Patchset 11 (id:??) landed as
https://crrev.com/8b3ed673a5787b3cc14a2a8cc8de7380cb4c1d88
Cr-Commit-Position: refs/heads/master@{#378586}