[Webkit-unassigned] [Bug 112327] Reorganize animation starting

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Apr 17 09:41:36 PDT 2013


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





--- Comment #13 from Simon Fraser (smfr) <simon.fraser at apple.com>  2013-04-17 09:39:52 PST ---
(From update of attachment 198478)
View in context: https://bugs.webkit.org/attachment.cgi?id=198478&action=review

I'm not sure I agree with this approach in general. It doesn't play nicely with threaded scrolling on Mac, for example; unless we test for restarting image animations while scrolling, we'll not see animated images when the threaded scrolling is happening.

> Source/WebCore/page/FrameView.cpp:4094
> +        stoppedAnimationBoundingBox = stoppedAnimation->absoluteBoundingBoxRect();

absoluteBoundingBoxRect() can be a fairly expensive call. I'm a bit concerned about the performance implications.

> Source/WebCore/page/FrameView.cpp:4110
> +        animationToResumeBoundingBox = animationToResume->absoluteBoundingBoxRect();

Why compute it twice?

> Source/WebCore/page/FrameView.cpp:4153
> +IntRect FrameView::computeScrolledViewPort(float deltaX, float deltaY)
> +{
> +    IntRect viewPort = visibleContentRect();
> +    int newX = viewPort.x() - deltaX;
> +    int newY = viewPort.y() - deltaY;
> +    IntRect scrolledViewPort(IntPoint(newX, newY), viewPort.size());
> +
> +    return scrolledViewPort;

Isn't this the same as visibleContentRect() or similar?

-- 
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