optimizing layout performance when only transform3d matrix changed by

optimizing layout performance when only transform3d matrix changed by
optimizing layout performance when only transform3d matrix changed by
removing unnecessary RecomputeCompositingRequirements overhead.

It takes long time in compositing stage for pages with many compositing layers 
such as www.famo.us. But it does not always need to do full 
compositing(including RecomputeCompositingRequirements and UpdateLayerTreeGeometry)
for some JS trigged css animations(js changes transform3d matrix). In this patch,
if only style Changed with css-transform3d-matrix, we can just do
UpdateLayerTreeGeometry, since no-composting layers added or removed. 
With this optimization, it improve www.famo.us fps from 10fps to 17fps.

BUG=337087

[yaojie.yan, 2014-03-18 08:53:36]

Hi,
I resubmitted the original patch(#185693002) to fix the Layout testing failure.
Now all the layout test pass. Could you help to review it? thanks

[Ian Vollick, 2014-03-18 11:59:15]

https://codereview.chromium.org/202683005/diff/1/Source/core/rendering/compos...
File Source/core/rendering/compositing/RenderLayerCompositor.cpp (right):

https://codereview.chromium.org/202683005/diff/1/Source/core/rendering/compos...
Source/core/rendering/compositing/RenderLayerCompositor.cpp:388: if
(m_layersChanged)
I think this is a layering violation. If I'm understanding this correctly, this
code is saying "if the layers changed the last time we computed compositing
requirements, we need to update the compositing requirements". It seems too late
at that point.

https://codereview.chromium.org/202683005/diff/1/Source/core/rendering/compos...
Source/core/rendering/compositing/RenderLayerCompositor.cpp:484: m_layersChanged
= layersChanged;
This value should not persist from update to update.

https://codereview.chromium.org/202683005/diff/1/Source/core/rendering/compos...
File Source/core/rendering/compositing/RenderLayerCompositor.h (right):

https://codereview.chromium.org/202683005/diff/1/Source/core/rendering/compos...
Source/core/rendering/compositing/RenderLayerCompositor.h:53:
CompositingMinUpdateAfterStyleChange,
"Min" and "fast" don't convey enough meaning.
How about,
CompositingUpdateAfterCompositedStyleChange,
..with a comment saying that if a property has changed in such a way that
compositing reasons cannot be impacted, then use this.

We should also use this for opacity (provided you're not transition to or from
1.0) and filters, where appropriate.

https://codereview.chromium.org/202683005/diff/1/Source/core/rendering/style/...
File Source/core/rendering/style/RenderStyleConstants.h (right):

https://codereview.chromium.org/202683005/diff/1/Source/core/rendering/style/...
Source/core/rendering/style/RenderStyleConstants.h:60:
StyleDifferenceRecompositeLayer,
Rather than adding "MinRecompositeLayer", could we make
StyleDifferenceRecompositeLayer mean what you intend here, and we could rename
the old enumerator to StyleDifferenceUpdateCompositingLayers to more accurately
indicate that more work will be done?

https://codereview.chromium.org/202683005/diff/1/Source/core/rendering/style/...
Source/core/rendering/style/RenderStyleConstants.h:79:
ContextSensitivePropertyTransform3D = (1 << 3)
I thought that transform, opacity and filter were supposed to be precisely that
set of properties that could be modified without affecting layout. Perhaps we
don't need a new enumerator here, and instead, we could check to see if the
style change for these properties could possibly affect compositing reasons, and
if not, we could use StyleDifferenceRecompositeLayer.

[abarth-chromium, 2014-03-18 15:22:23]

not lgtm

I don't think this change is correct conceptually.  If you change the transform
matrix of an element, you can cause different overlaps, which means we need to
re-run computeCompositingRequirements.

[Ian Vollick, 2014-03-18 15:39:55]

On 2014/03/18 15:22:23, abarth wrote:
> not lgtm
> 
> I don't think this change is correct conceptually.  If you change the
transform
> matrix of an element, you can cause different overlaps, which means we need to
> re-run computeCompositingRequirements.

This is a great point while we're still overlap testing. In today's code, some
opacity and filter changes, may skip compositing requirements updates, though,
and if we can get rid of overlap testing, we could get this optimization for
transforms, too.

[yaojie.yan, 2014-03-20 07:42:15]

On 2014/03/18 15:22:23, abarth wrote:
> not lgtm
> 
> I don't think this change is correct conceptually.  If you change the
transform
> matrix of an element, you can cause different overlaps, which means we need to
> re-run computeCompositingRequirements.
Hi abarth@
Yes, you are correct, but the famo.us is more specific case, the transform3d
object also is transparent. I think its transform do not effects the overlap
testing. The style for the object is:
< width: 120px; height: 160px; -webkit-transform: matrix3d(1, 0, 0, 0, 0, 1, 0,
0, 0, 0, 1, 0, 75, 270, 98825.76876598629, 1); OPACITY: 0.999999;
background-color: rgba(73, 160, 154, 0.294118)>

[yaojie.yan, 2014-03-20 07:43:19]

https://codereview.chromium.org/202683005/diff/1/Source/core/rendering/compos...
File Source/core/rendering/compositing/RenderLayerCompositor.cpp (right):

https://codereview.chromium.org/202683005/diff/1/Source/core/rendering/compos...
Source/core/rendering/compositing/RenderLayerCompositor.cpp:388: if
(m_layersChanged)
Yes, but my REAL purpose is to add some heuristic information here, if the
composting reasons did not changes for a long time, we will not need to
recomputingCompostingReasons for just transforms3d. I think there is the
tradeoff. Since it is a much overhead to recomputingCompostingReasons with
overlap for overmuch-layers page. Is it worthy to computing a pretty accurate a
GraphicsLayers Tree for just transforms3d case?

On 2014/03/18 11:59:16, Ian Vollick wrote:
> I think this is a layering violation. If I'm understanding this correctly,
this
> code is saying "if the layers changed the last time we computed compositing
> requirements, we need to update the compositing requirements". It seems too
late
> at that point.

https://codereview.chromium.org/202683005/diff/1/Source/core/rendering/style/...
File Source/core/rendering/style/RenderStyleConstants.h (right):

https://codereview.chromium.org/202683005/diff/1/Source/core/rendering/style/...
Source/core/rendering/style/RenderStyleConstants.h:79:
ContextSensitivePropertyTransform3D = (1 << 3)
Yes, I will address them in the following up patches.
On 2014/03/18 11:59:16, Ian Vollick wrote:
> I thought that transform, opacity and filter were supposed to be precisely
that
> set of properties that could be modified without affecting layout. Perhaps we
> don't need a new enumerator here, and instead, we could check to see if the
> style change for these properties could possibly affect compositing reasons,
and
> if not, we could use StyleDifferenceRecompositeLayer.

[abarth-chromium, 2014-03-20 16:09:57]

On 2014/03/20 07:42:15, yaojie.yan wrote:
> Yes, you are correct, but the famo.us is more specific case, the transform3d
> object also is transparent. I think its transform do not effects the overlap
> testing.

That's not correct.  If something later in paint order overlaps the element,
then it will need to be promoted due to overlap with the transformed element.

[dsinclair, 2016-03-01 01:25:12]

Description was changed from

==========
optimizing layout performance when only transform3d matrix changed by
optimizing layout performance when only transform3d matrix changed by
removing unnecessary RecomputeCompositingRequirements overhead.

It takes long time in compositing stage for pages with many compositing layers 
such as www.famo.us. But it does not always need to do full 
compositing(including RecomputeCompositingRequirements and
UpdateLayerTreeGeometry)
for some JS trigged css animations(js changes transform3d matrix). In this
patch,
if only style Changed with css-transform3d-matrix, we can just do
UpdateLayerTreeGeometry, since no-composting layers added or removed. 
With this optimization, it improve www.famo.us fps from 10fps to 17fps.

BUG=337087
==========

to

==========
optimizing layout performance when only transform3d matrix changed by
optimizing layout performance when only transform3d matrix changed by
removing unnecessary RecomputeCompositingRequirements overhead.

It takes long time in compositing stage for pages with many compositing layers 
such as www.famo.us. But it does not always need to do full 
compositing(including RecomputeCompositingRequirements and
UpdateLayerTreeGeometry)
for some JS trigged css animations(js changes transform3d matrix). In this
patch,
if only style Changed with css-transform3d-matrix, we can just do
UpdateLayerTreeGeometry, since no-composting layers added or removed. 
With this optimization, it improve www.famo.us fps from 10fps to 17fps.

BUG=337087
==========