Element is displayed behind a composited layer when clipping is used on a previous element
https://bugs.webkit.org/show_bug.cgi?id=104981

Reviewed by Simon Fraser.

Source/WebCore:

RenderLayerCompositor::computeCompositingRequirements uses the local bounding box of the layers to optimize the number of composited
layers that are created. That's needed in order to make sure that composited layers that are displayed behind non-composited
layers are correctly promoting the layers in front to be composited. Otherwise the non-composited layers are rendered
in the parent composited layer, displaying behind the other composited layers. That might be wrong as the correct paint order might not be
preserved.

In order to make animations work, there's a flag that will disable that optimization. That's because the animations run in the platform
layer and the platform layer doesn't know about the layers that are not promoted to composited layers. When the overlapping of the layers
is computed it just uses the start or the stop state, but no intermediate states. For that reason, all the 'top' layers in front of animated
elements will become composited.

When an animation has a clipping rectangle, then we know for sure that the animation is going to be contained inside the clip area, so WebKit
uses the bounding box of the clipping area to detect the overlapping layers, so there's no need to disable the optimization in that case.

However, if there is a different animation displaying behind the clipping container, we cannot safely disable that optimization anymore. That's
because we still don't know what are the intermediate states of that particular animated layer. The bug was that the optimization was re-enabled
anyway, even in this particular case.

In order to fix it, I changed the logic, so that instead of re-enabling the optimization after a clipping container, it will just avoid to propagate
the internal state to the following layers when there's no need to so.

Note that 3D transforms behave like animations for now and disable the optimization. Because of that some of the existing tests ended up
creating more layers than needed. That's because the tests had an overflow area that recreated the issue that this patch fixes, but with
3D transforms instead of animations. 3D transforms will be treated in a separate patch.

Tests: compositing/layer-creation/overlap-animation-clipping.html
       compositing/layer-creation/overlap-animation-container.html

* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::computeCompositingRequirements):

LayoutTests:

Updated existing test results and added two new tests to check that animations respect the correct paint order,
even though they are painted with composited layers.

Note that there are side effects of this patch that will be corrected in a following bug. 3D layers are treated like animations, so they
disable the overlapping optimizations. Because of that, some of the test results were updated to include the layers that, previously,
were not created as a result of being in front of a "clipping container".

* compositing/geometry/foreground-layer-expected.txt:
* compositing/layer-creation/overlap-animation-clipping-expected.txt: Added.
* compositing/layer-creation/overlap-animation-clipping.html: Added. Checking that the animation inside a clipping container is not
affecting how we compute the animations outside the clipping container.
* compositing/layer-creation/overlap-animation-container-expected.txt: Added.
* compositing/layer-creation/overlap-animation-container.html: Added. Checking that we don't create unnecessary composited layers for layers inside
composited containers that draw in front of animated layers.
* compositing/overflow/clip-descendents-expected.txt:
* compositing/overflow/clip-descendents.html: Removed the text from the output, so that platforms can share the same expected result.
* platform/chromium-win/compositing/overflow/clip-descendents-expected.txt: Removed. Not needed anymore, all Chromium platforms can share the same results now.
* platform/chromium/compositing/geometry/foreground-layer-expected.txt:
* platform/chromium/compositing/layer-creation/overlap-animation-clipping-expected.txt: Added.
* platform/chromium/compositing/layer-creation/overlap-animation-container-expected.txt: Added.
* platform/chromium/compositing/layer-creation/overlap-transformed-3d-expected.txt: Added.
* platform/chromium/compositing/layer-creation/overlap-transforms-expected.txt:
* platform/chromium/compositing/overflow/clip-descendents-expected.txt: Renamed from LayoutTests/platform/chromium-mac/compositing/overflow/clip-descendents-expected.txt.
* platform/qt/compositing/overflow/clip-descendents-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139493 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Don't regenerate all bindings when any idl file changes
https://bugs.webkit.org/show_bug.cgi?id=106604

Reviewed by Kentaro Hara.

Source/WebCore:

Currently, every idl file is a dependency of generating the supplemental dependency map
and generating bindings is a dependency of the map. This means that touching any idl file
causes us to regenerate all the bindings.

Change it so that generating bindings only depends on the idl files that have Supplemental= in them.
We only have 24 idl files with Supplemental (3.7% of the 638 idl files in WebCore) so modifying
any of those will cause all bindings to be regenerated.

If you add or remove a new idl file, you have to rerun gyp which will fix up any dependencies.
If you edit an existing file and add Supplemental= to it, you will now need to rerun gyp_{webkit,chromium}.
I think that's a reasonable tradeoff since it seems highly unlikely that you would adding Supplemental=
to an existing file without renaming it. The bots will always be fine because they always run
gyp after updating.

No new tests, this is a build only change.

* WebCore.gyp/WebCore.gyp: Remove <(SHARED_INTERMEDIATE_DIR)/supplemental_dependency.tmp, which was causing
the full rebuild. The step to generate this file is still a hard dependency so it will still be generated and
used by generate-bindings.pl. Also remove <@(webcore_test_support_idl_files). This was saying we should regenerate
all bindings if a test idl file changed. That doesn't make sense.
* WebCore.gyp/scripts/supplemental_idl_files.py: Added.
(DoMain):

Source/WebKit/chromium:

* gyp_webkit: Add Source/WebCore/WebCore.gyp/scripts to the python import search path
so we can generate idl dependencies at gyp time.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139494 268f45cc-cd09-0410-ab3c-d52691b4dbfc