[Webkit-unassigned] [Bug 99669] hover, layout and scrolling super slow

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Oct 26 17:08:06 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=99669





--- Comment #19 from Simon Fraser (smfr) <simon.fraser at apple.com>  2012-10-26 17:09:15 PST ---
(In reply to comment #17)
> James walked me through the compositing code. The culprit here is the following code in RenderLayerCompositor::computeCompositingRequirements:
>     // Turn overlap testing off for later layers if it's already off, or if we have a 3D transform or an animating transform.
>     if (!childState.m_testingOverlap || layer->has3DTransform() || isRunningAcceleratedTransformAnimation(layer->renderer()))
>         compositingState.m_testingOverlap = false;
> 
> Since we don't know the bounds of the animation / transform, we disable all overlap testing and recomposite the world. I confirmed that commenting out these two lines makes this test case fast.
> 
> Some ideas from James as to how to fix this:
> 1. compute tighter bounds on the layer with the animation and feed that into the overlap test

In theory we could look at the animation endpoints (and keyframes if any) and compute a bounding box for all steps of the animation. That would certainly help.

> 2. composite all of these potentially-overlapping things into one composited layer instead of N

Do to this you'd have to figure out that doing so doesn't break the visual ordering. Also, it's not clear that it would help performance here.

> 3. make computing all of this faster

That would help in general.

> These all sound hard. :) 
> 
> Thinking about 3, in the Chromium composited profile:
> -20% is spent in TilingData::tileRect. That function seems pretty fast though, so presumably it's just getting called a ton.
> -30% is spent in RenderLayerBacking::~RenderLayerBacking, which spends most of its time in RenderLayerBacking::updateClippingLayers.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list