Created attachment 248849[details]
RenderLayerCompositor: only create backing for visible and non-empty layers
When there is at least one layer that requires compositing in the page, like accelerated canvas or so, all overlapped layers creates their own backing even if initially unvisible (and even with 0 width or height)
Not sure that the following patch has the best approach tough but worth to have a try on layout tests on webkit's buildbots.
Other approach could be to make the layer that are in the same zindex, use the same backing.
This will break all kinds of things: transitions on a visibility:hidden layer that toggles to visible, visible children of a hidden composited layer etc.
Created attachment 248852[details]
RenderLayerCompositor: only create backing for visible and non-empty layers
In last patch I forgot to actually activate my change :) so previous patch was doing nothing.
Created attachment 248943[details]
Example of positionned divs
In the attached exmaple, all the divs become composited (creates a backing), because of the video tag.
If the video tag is added after all the divs or in a zindex different than 0 then all the divs do not become composited.
So is it really an expected behaviour for neasted divs to all become composited this way ?
You can use the attached patched to print info on composited layers.
About stacking context the following doc is very helpful:
"When no z-index property is specified, elements are rendered on the default rendering layer 0 (zero)." , but if I put 0 manually the divs do not become composited (if I put auto they become composited)
"A stacking context is formed, anywhere in the document, by any element which is positioned (absolutely or relatively) with a z-index value other than "auto" "
It seems to behave the opposite as said juste before.
https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Understanding_z_index/The_stacking_contexthttps://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Understanding_z_index/Stacking_without_z-index
(In reply to comment #4)
> Created attachment 248943[details]
> Example of positionned divs
>
> In the attached exmaple, all the divs become composited (creates a backing),
> because of the video tag.
Not on Mac. I get one big layer for the rootmost view and none inside of it.
> If the video tag is added after all the divs or in a zindex different than 0
> then all the divs do not become composited.
Odd that there's an ordering difference.
> So is it really an expected behaviour for neasted divs to all become
> composited this way ?
No. Are you testing webkit TOT?
> About stacking context the following doc is very helpful:
>
> "When no z-index property is specified, elements are rendered on the default
> rendering layer 0 (zero)." , but if I put 0 manually the divs do not become
> composited (if I put auto they become composited)
>
> "A stacking context is formed, anywhere in the document, by any element
> which is positioned (absolutely or relatively) with a z-index value other
> than "auto" "
> It seems to behave the opposite as said juste before.
z-index:0 create stacking context, but has z-index 0 in its parent stacking context. z-index: auto does not create stacking context.
I am testing on webkitgtk and webkitefl with latest webkit code.
That's good to know that you get good behavior on osx. I'll investigate more tomorrow. I'll try to understand why all the divs become composited even if I set z-index to auto (the default).
(In reply to comment #6)
> (In reply to comment #4)
> > Created attachment 248943[details]
> > Example of positionned divs
> >
> > In the attached exmaple, all the divs become composited (creates a backing),
> > because of the video tag.
>
> Not on Mac. I get one big layer for the rootmost view and none inside of it.
>
> > If the video tag is added after all the divs or in a zindex different than 0
> > then all the divs do not become composited.
>
> Odd that there's an ordering difference.
>
> > So is it really an expected behaviour for neasted divs to all become
> > composited this way ?
>
> No. Are you testing webkit TOT?
>
> > About stacking context the following doc is very helpful:
> >
> > "When no z-index property is specified, elements are rendered on the default
> > rendering layer 0 (zero)." , but if I put 0 manually the divs do not become
> > composited (if I put auto they become composited)
> >
> > "A stacking context is formed, anywhere in the document, by any element
> > which is positioned (absolutely or relatively) with a z-index value other
> > than "auto" "
> > It seems to behave the opposite as said juste before.
>
> z-index:0 create stacking context, but has z-index 0 in its parent stacking
> context. z-index: auto does not create stacking context.
Actually, in the example Julien attached all divs have -index: 0;.
So if you used the same unmodified example you got wrong behaviour on Mac.
(In reply to comment #8)
> Actually, in the example Julien attached all divs have -index: 0;.
> So if you used the same unmodified example you got wrong behaviour on Mac.
Can you attach a testcase that actually shows the bug?
Created attachment 249039[details]
Example of positionned divs
It'll try to make a proper layout test but for now this example make all the div be composited. You can see it using WEBKIT_DEBUG="compositing". Whereas z-index=auto should prevent them creating a stacking context (backing).
Created attachment 249040[details]
WIP: only accept indirect reason if the layer can be a stacking context (composited)
WIP patch just to run layout tests.
OK, what I see on Mac with that testcase is a bunch of compositing layers, but most of them have no backing store so are cheap.
This is expected behavior; there's no enclosing stacking context, so each position:relative layer gets composited.
Blink wrote some "layer flattening" code to solve this, but it's complex and hard to get right.
Attachment 249040[details] did not pass style-queue:
ERROR: Source/WebCore/rendering/RenderLayer.h:946: More than one command on the same line in if [whitespace/parens] [4]
Total errors found: 1 in 1 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 249044[details]
Archive of layout-test-results from ews105 for mac-mavericks-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
Created attachment 249047[details]
Archive of layout-test-results from ews101 for mac-mavericks
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews101 Port: mac-mavericks Platform: Mac OS X 10.9.5
Created attachment 249146[details]
Archive of layout-test-results from ews206 for win-future
The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews206 Port: win-future Platform: CYGWIN_NT-6.1-WOW64-1.7.20-0.266-5-3-i686-32bit
I checked an indeed a backingstore is created only when CoordinatedGraphicsScene/layerShouldHaveBackingStore
"drawsContent() && contentsAreVisible() && !size().isEmpty()" return true.
At each call to CoordinatedGraphicsScene::setLayerState it checks if this condition return false to see if it can remove the backingstore.
So in RenderLayerCompositor::computeCompositingRequirements, when the layer is "RenderBlock HTML":
if (layer.isStackingContainer())
if (Vector<RenderLayer*>* posZOrderList = layer.posZOrderList())
for (auto* renderLayer : *posZOrderList)
computeCompositingRequirements
The posZOrderList contains the 11 divs.
Then within a call to computeCompositingRequirements for each of these 11 divs, compositingReason = overlapMap.overlapsLayers returns IndirectCompositingReason::Overlap (which make it composited) because m_overlapStack.last() is the rect of the video layer.
Indeed each divs is push and then pop from the overlapmap because of:
if (childState.compositingAncestor == &layer && !layer.isRootLayer())
overlapMap.popCompositingContainer();
So for each div it always compares to video rect, even if these divs are nested.
As opposite, when z-index is force to 0 in the attached example, posZOrderList is 2 (video tag and first div) and the m_overlapStack.last() is the first div (which one is made composited).
So except the first div, compositingReason = overlapMap.overlapsLayers is compared to the first div. So it returns IndirectCompositingReason::None.
In the end having z-index to auto make it the nested divs behaves as if there were not nested. Is it expected ? Well as least it follows the rules that auto means it does not create a stacking context (except for the root layer)
Created attachment 249242[details]
WIP: for overlap composited reasins check if the layer is visually non empty
I am still not happy with this patch since it should make a composite layer for the first div (in both zindex cases: 0/auto)
But I am curious of the layout tests result.
Created attachment 249244[details]
WIP: for overlap composited reasins check if the layer is visually non empty and stacking context
This one is better for z-index 0 case.
Comment on attachment 249242[details]
WIP: for overlap composited reasins check if the layer is visually non empty
Attachment 249242[details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/4565102678245376
New failing tests:
compositing/geometry/bounds-ignores-hidden-dynamic-negzindex.html
compositing/geometry/fixed-position-flipped-writing-mode.html
compositing/visibility/layer-visible-content.html
css3/blending/blend-mode-blended-element-overlapping-composited-sibling-should-have-compositing-layer.html
Created attachment 249250[details]
Archive of layout-test-results from ews107 for mac-mavericks-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
Comment on attachment 249242[details]
WIP: for overlap composited reasins check if the layer is visually non empty
Attachment 249242[details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/5837877044838400
New failing tests:
compositing/geometry/bounds-ignores-hidden-dynamic-negzindex.html
compositing/visibility/layer-visible-content.html
css3/blending/blend-mode-blended-element-overlapping-composited-sibling-should-have-compositing-layer.html
Created attachment 249251[details]
Archive of layout-test-results from ews102 for mac-mavericks
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102 Port: mac-mavericks Platform: Mac OS X 10.9.5
Comment on attachment 249335[details]
RenderLayerCompositor: avoid creating unecessary composited layers when not stacking context.
This patch has been pending review since 2015 with no recent activity.
It seems unlikely that it would even still apply to trunk in its current form.
Clearing from the review queue.
Feel free to update and resubmit if the patch is still relevant.
2015-03-17 08:53 PDT, Julien Isorce
2015-03-17 10:37 PDT, Julien Isorce
2015-03-18 11:12 PDT, Julien Isorce
2015-03-18 11:22 PDT, Julien Isorce
2015-03-19 11:41 PDT, Julien Isorce
2015-03-19 11:42 PDT, Julien Isorce
2015-03-19 12:12 PDT, Build Bot
2015-03-19 12:24 PDT, Build Bot
2015-03-20 16:31 PDT, Build Bot
2015-03-23 11:34 PDT, Julien Isorce
2015-03-23 11:41 PDT, Julien Isorce
2015-03-23 12:28 PDT, Build Bot
2015-03-23 12:30 PDT, Build Bot
2015-03-24 11:22 PDT, Julien Isorce
2015-03-24 11:25 PDT, Julien Isorce