[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