haikuwebkit/LayoutTests/fast/animation/request-animation-frame-thr...

24 lines
734 B
HTML
Raw Permalink Normal View History

Throttle RequestAnimationFrame in subframes that are outside the viewport https://bugs.webkit.org/show_bug.cgi?id=144718 <rdar://problem/20688782> Reviewed by Simon Fraser. Source/WebCore: Throttle RequestAnimationFrame in subframes that are outside the viewport or have "display: none" for performance and power. Tests: fast/animation/request-animation-frame-throttle-subframe-display-none.html fast/animation/request-animation-frame-throttle-subframe.html * dom/Document.h: (WebCore::Document::scriptedAnimationController): * dom/ScriptedAnimationController.cpp: (WebCore::ScriptedAnimationController::setThrottled): (WebCore::ScriptedAnimationController::isThrottled): * dom/ScriptedAnimationController.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::open): Call FrameView::setFrameRect() only *after* the view has been set on the Frame. Otherwise, setFrameRect() ends up calling viewportContentsChanged() and we hit the ASSERT(frame().view() == this) assertion in windowClipRect() because the Frame still has its old FrameView. This is covered by loader/go-back-to-different-window-size.html layout test. * page/FrameView.cpp: (WebCore::FrameView::viewportContentsChanged): (WebCore::FrameView::applyRecursivelyWithVisibleRect): (WebCore::FrameView::resumeVisibleImageAnimations): (WebCore::FrameView::updateScriptedAnimationsThrottlingState): (WebCore::FrameView::resumeVisibleImageAnimationsIncludingSubframes): (WebCore::FrameView::updateThrottledDOMTimersState): (WebCore::FrameView::scrollPositionChanged): Deleted. (WebCore::FrameView::sendResizeEventIfNeeded): Deleted. * page/FrameView.h: * testing/Internals.cpp: (WebCore::Internals::isRequestAnimationFrameThrottled): (WebCore::Internals::isTimerThrottled): Deleted. * testing/Internals.h: * testing/Internals.idl: LayoutTests: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe-display-none.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in "display: none" subframes. * fast/animation/request-animation-frame-throttle-subframe-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in frames that are outside the viewport. * fast/animation/resources/requestAnimationFrame-frame-2.html: Added. * fast/animation/resources/requestAnimationFrame-frame.html: Added. * platform/win/TestExpectations: Skip the 2 new tests on Windows as requestAnimationFrame throttling is only supported on Cocoa. Canonical link: https://commits.webkit.org/162829@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@183998 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-05-08 18:15:57 +00:00
<!DOCTYPE html>
<html>
<body>
<script src="../../resources/js-test-pre.js"></script>
<script>
Regression(183998): Disqus comments take a very long time to load https://bugs.webkit.org/show_bug.cgi?id=146522 <rdar://problem/21590601> Reviewed by Simon Fraser. Source/WebCore: Stop throttling requestAnimationFrame() in iframes that are not visible due to them being zero-sized or display:none. Those are usually utility iframes and throttling them is risky. Se still throttle requestAnimationFrame() in iframes that would be visible in theory but are currently not noticeable because they are outside the viewport. Test: - fast/animation/request-animation-frame-throttle-subframe.html - fast/animation/request-animation-frame-throttle-subframe-display-none.html - fast/animation/request-animation-frame-throttle-subframe-zero-size.html * page/FrameView.cpp: (WebCore::FrameView::updateScriptedAnimationsAndTimersThrottlingState): LayoutTests: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: * fast/animation/request-animation-frame-throttle-subframe-display-none.html: Update layout test as we changed behavior here. We no longer throttle display:none iframes. * fast/animation/request-animation-frame-throttle-subframe-zero-size-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe-zero-size.html: Added. Add layout test to check that we don't throttle RaF in iframes that are zero-sized. * fast/animation/resources/requestAnimationFrame-frame-2.html: * fast/animation/resources/requestAnimationFrame-frame.html: Update use of requestAnimationFrame() to be more representative of real world usage. Canonical link: https://commits.webkit.org/164609@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@186195 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-07-01 21:52:07 +00:00
description("Tests that requestAnimationFrame is not throttled in subframes that are display:none");
Throttle RequestAnimationFrame in subframes that are outside the viewport https://bugs.webkit.org/show_bug.cgi?id=144718 <rdar://problem/20688782> Reviewed by Simon Fraser. Source/WebCore: Throttle RequestAnimationFrame in subframes that are outside the viewport or have "display: none" for performance and power. Tests: fast/animation/request-animation-frame-throttle-subframe-display-none.html fast/animation/request-animation-frame-throttle-subframe.html * dom/Document.h: (WebCore::Document::scriptedAnimationController): * dom/ScriptedAnimationController.cpp: (WebCore::ScriptedAnimationController::setThrottled): (WebCore::ScriptedAnimationController::isThrottled): * dom/ScriptedAnimationController.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::open): Call FrameView::setFrameRect() only *after* the view has been set on the Frame. Otherwise, setFrameRect() ends up calling viewportContentsChanged() and we hit the ASSERT(frame().view() == this) assertion in windowClipRect() because the Frame still has its old FrameView. This is covered by loader/go-back-to-different-window-size.html layout test. * page/FrameView.cpp: (WebCore::FrameView::viewportContentsChanged): (WebCore::FrameView::applyRecursivelyWithVisibleRect): (WebCore::FrameView::resumeVisibleImageAnimations): (WebCore::FrameView::updateScriptedAnimationsThrottlingState): (WebCore::FrameView::resumeVisibleImageAnimationsIncludingSubframes): (WebCore::FrameView::updateThrottledDOMTimersState): (WebCore::FrameView::scrollPositionChanged): Deleted. (WebCore::FrameView::sendResizeEventIfNeeded): Deleted. * page/FrameView.h: * testing/Internals.cpp: (WebCore::Internals::isRequestAnimationFrameThrottled): (WebCore::Internals::isTimerThrottled): Deleted. * testing/Internals.h: * testing/Internals.idl: LayoutTests: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe-display-none.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in "display: none" subframes. * fast/animation/request-animation-frame-throttle-subframe-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in frames that are outside the viewport. * fast/animation/resources/requestAnimationFrame-frame-2.html: Added. * fast/animation/resources/requestAnimationFrame-frame.html: Added. * platform/win/TestExpectations: Skip the 2 new tests on Windows as requestAnimationFrame throttling is only supported on Cocoa. Canonical link: https://commits.webkit.org/162829@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@183998 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-05-08 18:15:57 +00:00
window.jsTestIsAsync = true;
Regression(183998): Disqus comments take a very long time to load https://bugs.webkit.org/show_bug.cgi?id=146522 <rdar://problem/21590601> Reviewed by Simon Fraser. Source/WebCore: Stop throttling requestAnimationFrame() in iframes that are not visible due to them being zero-sized or display:none. Those are usually utility iframes and throttling them is risky. Se still throttle requestAnimationFrame() in iframes that would be visible in theory but are currently not noticeable because they are outside the viewport. Test: - fast/animation/request-animation-frame-throttle-subframe.html - fast/animation/request-animation-frame-throttle-subframe-display-none.html - fast/animation/request-animation-frame-throttle-subframe-zero-size.html * page/FrameView.cpp: (WebCore::FrameView::updateScriptedAnimationsAndTimersThrottlingState): LayoutTests: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: * fast/animation/request-animation-frame-throttle-subframe-display-none.html: Update layout test as we changed behavior here. We no longer throttle display:none iframes. * fast/animation/request-animation-frame-throttle-subframe-zero-size-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe-zero-size.html: Added. Add layout test to check that we don't throttle RaF in iframes that are zero-sized. * fast/animation/resources/requestAnimationFrame-frame-2.html: * fast/animation/resources/requestAnimationFrame-frame.html: Update use of requestAnimationFrame() to be more representative of real world usage. Canonical link: https://commits.webkit.org/164609@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@186195 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-07-01 21:52:07 +00:00
function runTest()
Throttle RequestAnimationFrame in subframes that are outside the viewport https://bugs.webkit.org/show_bug.cgi?id=144718 <rdar://problem/20688782> Reviewed by Simon Fraser. Source/WebCore: Throttle RequestAnimationFrame in subframes that are outside the viewport or have "display: none" for performance and power. Tests: fast/animation/request-animation-frame-throttle-subframe-display-none.html fast/animation/request-animation-frame-throttle-subframe.html * dom/Document.h: (WebCore::Document::scriptedAnimationController): * dom/ScriptedAnimationController.cpp: (WebCore::ScriptedAnimationController::setThrottled): (WebCore::ScriptedAnimationController::isThrottled): * dom/ScriptedAnimationController.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::open): Call FrameView::setFrameRect() only *after* the view has been set on the Frame. Otherwise, setFrameRect() ends up calling viewportContentsChanged() and we hit the ASSERT(frame().view() == this) assertion in windowClipRect() because the Frame still has its old FrameView. This is covered by loader/go-back-to-different-window-size.html layout test. * page/FrameView.cpp: (WebCore::FrameView::viewportContentsChanged): (WebCore::FrameView::applyRecursivelyWithVisibleRect): (WebCore::FrameView::resumeVisibleImageAnimations): (WebCore::FrameView::updateScriptedAnimationsThrottlingState): (WebCore::FrameView::resumeVisibleImageAnimationsIncludingSubframes): (WebCore::FrameView::updateThrottledDOMTimersState): (WebCore::FrameView::scrollPositionChanged): Deleted. (WebCore::FrameView::sendResizeEventIfNeeded): Deleted. * page/FrameView.h: * testing/Internals.cpp: (WebCore::Internals::isRequestAnimationFrameThrottled): (WebCore::Internals::isTimerThrottled): Deleted. * testing/Internals.h: * testing/Internals.idl: LayoutTests: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe-display-none.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in "display: none" subframes. * fast/animation/request-animation-frame-throttle-subframe-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in frames that are outside the viewport. * fast/animation/resources/requestAnimationFrame-frame-2.html: Added. * fast/animation/resources/requestAnimationFrame-frame.html: Added. * platform/win/TestExpectations: Skip the 2 new tests on Windows as requestAnimationFrame throttling is only supported on Cocoa. Canonical link: https://commits.webkit.org/162829@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@183998 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-05-08 18:15:57 +00:00
{
Regression(183998): Disqus comments take a very long time to load https://bugs.webkit.org/show_bug.cgi?id=146522 <rdar://problem/21590601> Reviewed by Simon Fraser. Source/WebCore: Stop throttling requestAnimationFrame() in iframes that are not visible due to them being zero-sized or display:none. Those are usually utility iframes and throttling them is risky. Se still throttle requestAnimationFrame() in iframes that would be visible in theory but are currently not noticeable because they are outside the viewport. Test: - fast/animation/request-animation-frame-throttle-subframe.html - fast/animation/request-animation-frame-throttle-subframe-display-none.html - fast/animation/request-animation-frame-throttle-subframe-zero-size.html * page/FrameView.cpp: (WebCore::FrameView::updateScriptedAnimationsAndTimersThrottlingState): LayoutTests: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: * fast/animation/request-animation-frame-throttle-subframe-display-none.html: Update layout test as we changed behavior here. We no longer throttle display:none iframes. * fast/animation/request-animation-frame-throttle-subframe-zero-size-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe-zero-size.html: Added. Add layout test to check that we don't throttle RaF in iframes that are zero-sized. * fast/animation/resources/requestAnimationFrame-frame-2.html: * fast/animation/resources/requestAnimationFrame-frame.html: Update use of requestAnimationFrame() to be more representative of real world usage. Canonical link: https://commits.webkit.org/164609@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@186195 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-07-01 21:52:07 +00:00
testFrame = document.getElementById("testFrame");
Throttle RequestAnimationFrame in subframes that are outside the viewport https://bugs.webkit.org/show_bug.cgi?id=144718 <rdar://problem/20688782> Reviewed by Simon Fraser. Source/WebCore: Throttle RequestAnimationFrame in subframes that are outside the viewport or have "display: none" for performance and power. Tests: fast/animation/request-animation-frame-throttle-subframe-display-none.html fast/animation/request-animation-frame-throttle-subframe.html * dom/Document.h: (WebCore::Document::scriptedAnimationController): * dom/ScriptedAnimationController.cpp: (WebCore::ScriptedAnimationController::setThrottled): (WebCore::ScriptedAnimationController::isThrottled): * dom/ScriptedAnimationController.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::open): Call FrameView::setFrameRect() only *after* the view has been set on the Frame. Otherwise, setFrameRect() ends up calling viewportContentsChanged() and we hit the ASSERT(frame().view() == this) assertion in windowClipRect() because the Frame still has its old FrameView. This is covered by loader/go-back-to-different-window-size.html layout test. * page/FrameView.cpp: (WebCore::FrameView::viewportContentsChanged): (WebCore::FrameView::applyRecursivelyWithVisibleRect): (WebCore::FrameView::resumeVisibleImageAnimations): (WebCore::FrameView::updateScriptedAnimationsThrottlingState): (WebCore::FrameView::resumeVisibleImageAnimationsIncludingSubframes): (WebCore::FrameView::updateThrottledDOMTimersState): (WebCore::FrameView::scrollPositionChanged): Deleted. (WebCore::FrameView::sendResizeEventIfNeeded): Deleted. * page/FrameView.h: * testing/Internals.cpp: (WebCore::Internals::isRequestAnimationFrameThrottled): (WebCore::Internals::isTimerThrottled): Deleted. * testing/Internals.h: * testing/Internals.idl: LayoutTests: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe-display-none.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in "display: none" subframes. * fast/animation/request-animation-frame-throttle-subframe-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in frames that are outside the viewport. * fast/animation/resources/requestAnimationFrame-frame-2.html: Added. * fast/animation/resources/requestAnimationFrame-frame.html: Added. * platform/win/TestExpectations: Skip the 2 new tests on Windows as requestAnimationFrame throttling is only supported on Cocoa. Canonical link: https://commits.webkit.org/162829@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@183998 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-05-08 18:15:57 +00:00
Regression(183998): Disqus comments take a very long time to load https://bugs.webkit.org/show_bug.cgi?id=146522 <rdar://problem/21590601> Reviewed by Simon Fraser. Source/WebCore: Stop throttling requestAnimationFrame() in iframes that are not visible due to them being zero-sized or display:none. Those are usually utility iframes and throttling them is risky. Se still throttle requestAnimationFrame() in iframes that would be visible in theory but are currently not noticeable because they are outside the viewport. Test: - fast/animation/request-animation-frame-throttle-subframe.html - fast/animation/request-animation-frame-throttle-subframe-display-none.html - fast/animation/request-animation-frame-throttle-subframe-zero-size.html * page/FrameView.cpp: (WebCore::FrameView::updateScriptedAnimationsAndTimersThrottlingState): LayoutTests: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: * fast/animation/request-animation-frame-throttle-subframe-display-none.html: Update layout test as we changed behavior here. We no longer throttle display:none iframes. * fast/animation/request-animation-frame-throttle-subframe-zero-size-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe-zero-size.html: Added. Add layout test to check that we don't throttle RaF in iframes that are zero-sized. * fast/animation/resources/requestAnimationFrame-frame-2.html: * fast/animation/resources/requestAnimationFrame-frame.html: Update use of requestAnimationFrame() to be more representative of real world usage. Canonical link: https://commits.webkit.org/164609@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@186195 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-07-01 21:52:07 +00:00
// Force layout.
document.body.offsetTop;
Throttle RequestAnimationFrame in subframes that are outside the viewport https://bugs.webkit.org/show_bug.cgi?id=144718 <rdar://problem/20688782> Reviewed by Simon Fraser. Source/WebCore: Throttle RequestAnimationFrame in subframes that are outside the viewport or have "display: none" for performance and power. Tests: fast/animation/request-animation-frame-throttle-subframe-display-none.html fast/animation/request-animation-frame-throttle-subframe.html * dom/Document.h: (WebCore::Document::scriptedAnimationController): * dom/ScriptedAnimationController.cpp: (WebCore::ScriptedAnimationController::setThrottled): (WebCore::ScriptedAnimationController::isThrottled): * dom/ScriptedAnimationController.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::open): Call FrameView::setFrameRect() only *after* the view has been set on the Frame. Otherwise, setFrameRect() ends up calling viewportContentsChanged() and we hit the ASSERT(frame().view() == this) assertion in windowClipRect() because the Frame still has its old FrameView. This is covered by loader/go-back-to-different-window-size.html layout test. * page/FrameView.cpp: (WebCore::FrameView::viewportContentsChanged): (WebCore::FrameView::applyRecursivelyWithVisibleRect): (WebCore::FrameView::resumeVisibleImageAnimations): (WebCore::FrameView::updateScriptedAnimationsThrottlingState): (WebCore::FrameView::resumeVisibleImageAnimationsIncludingSubframes): (WebCore::FrameView::updateThrottledDOMTimersState): (WebCore::FrameView::scrollPositionChanged): Deleted. (WebCore::FrameView::sendResizeEventIfNeeded): Deleted. * page/FrameView.h: * testing/Internals.cpp: (WebCore::Internals::isRequestAnimationFrameThrottled): (WebCore::Internals::isTimerThrottled): Deleted. * testing/Internals.h: * testing/Internals.idl: LayoutTests: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe-display-none.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in "display: none" subframes. * fast/animation/request-animation-frame-throttle-subframe-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in frames that are outside the viewport. * fast/animation/resources/requestAnimationFrame-frame-2.html: Added. * fast/animation/resources/requestAnimationFrame-frame.html: Added. * platform/win/TestExpectations: Skip the 2 new tests on Windows as requestAnimationFrame throttling is only supported on Cocoa. Canonical link: https://commits.webkit.org/162829@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@183998 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-05-08 18:15:57 +00:00
Throttling requestAnimationFrame should be controlled by RenderingUpdateScheduler https://bugs.webkit.org/show_bug.cgi?id=204713 Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2020-05-04 Reviewed by Simon Fraser. Source/WebCore: rAF and Page rendering were managed by two different timers. Throttling rAF was implemented by changing its timer. After r242624, RenderingUpdate steps have been managed by RenderingUpdateScheduler. This means rAF is now serviced by the preferredFramesPerSecond which is 60 fps regardless it's throttled or not. Moreover the rAF throttling timer was mistakenly kept and it has been running under the old assumption which is: rAF is serviced by a timer only. This means rAF will be serviced by its timer and by the RenderingUpdate steps at the same time when it is supposed to throttle. This will make it fire more than 60 fps in cases which it is supposed to run less than 60 fps. The solution is to have two throttling types: 1) Page throttling (or full throttling): This slows down all the steps of RenderingUpdate for the main document and all the sub-documents. Page throttling reasons are: -- VisuallyIdle: Aggressive throttling. -- LowPowerMode: Half speed throttling. 2) Document throttling (or partial throttling): This only slows down the rAF of a certain document. Document throttling reasons are: -- OutsideViewport: Aggressive throttling. -- NonInteractedCrossOriginFrame: Half speed throttling. RenderingUpdate steps will still be managed by RenderingUpdateScheduler which can be throttled. The assumption is none of these steps will need to run faster than the Page preferredFramesPerSecond. If rAF wants to run slower than the Page because of a Document throttling reason, no rAF callbacks will be serviced before its preferredFrameInterval has elapsed. In this patch, "Half speed throttling" is only implemented for the Page and the Document throttling. The "Aggressive throttling" will be done in following patches. Page rendering was never throttled before. We need to make sure this is not going to affect PLT. Some tests need to be changed and new tests need to be written. All of the throttling tests checks the state of the code but none of them checks the real user's experience. * Headers.cmake: * WebCore.xcodeproj/project.pbxproj: * animation/DocumentTimeline.cpp: (WebCore::DocumentTimeline::animationInterval const): (WebCore::DocumentTimeline::updateThrottlingState): Deleted. * animation/DocumentTimeline.h: There is no need to have DocumentTimeline throttling. It is already throttled when the page RenderingUpdate is throttled. * dom/Document.cpp: (WebCore::Document::requestAnimationFrame): (WebCore::Document::updateLastHandledUserGestureTimestamp): LowPowerMode throttling is now handled by the Page. So remove its handling from the Document. * dom/ScriptedAnimationController.cpp: (WebCore::ScriptedAnimationController::ScriptedAnimationController): (WebCore::ScriptedAnimationController::page const): (WebCore::ScriptedAnimationController::interval const): (WebCore::ScriptedAnimationController::preferredScriptedAnimationInterval const): (WebCore::ScriptedAnimationController::throttlingReasons const): (WebCore::ScriptedAnimationController::isThrottledRelativeToPage const): (WebCore::ScriptedAnimationController::shouldRescheduleRequestAnimationFrame const): (WebCore::ScriptedAnimationController::registerCallback): (WebCore::ScriptedAnimationController::cancelCallback): (WebCore::ScriptedAnimationController::serviceRequestAnimationFrameCallbacks): (WebCore::ScriptedAnimationController::scheduleAnimation): (WebCore::throttlingReasonToString): Deleted. (WebCore::throttlingReasonsToString): Deleted. (WebCore::ScriptedAnimationController::addThrottlingReason): Deleted. (WebCore::ScriptedAnimationController::removeThrottlingReason): Deleted. (WebCore::ScriptedAnimationController::isThrottled const): Deleted. (WebCore::ScriptedAnimationController::animationTimerFired): Deleted. * dom/ScriptedAnimationController.h: (WebCore::ScriptedAnimationController::addThrottlingReason): (WebCore::ScriptedAnimationController::removeThrottlingReason): Get rid of the rAF throttling timer. Service the rAF callback only when the period from the current time stamp till the last service time stamp is greater than the preferred rAF interval. * page/FrameView.cpp: (WebCore::FrameView::updateScriptedAnimationsAndTimersThrottlingState): ThrottlingReason is now defined outside ScriptedAnimationController. * page/Page.cpp: (WebCore::m_loadsFromNetwork): (WebCore::Page::setLowPowerModeEnabledOverrideForTesting): (WebCore::Page::preferredRenderingUpdateInterval const): Calculate the preferred RenderingUpdate interval from the throttling reasons. (WebCore::Page::setIsVisuallyIdleInternal): (WebCore::Page::handleLowModePowerChange): Call adjustRenderingUpdateFrequency() when isLowPowerModeEnabled or IsVisuallyIdle is toggled. (WebCore::Page::isLowPowerModeEnabled const): Deleted. (WebCore::updateScriptedAnimationsThrottlingReason): Deleted. * page/Page.h: (WebCore::Page::isLowPowerModeEnabled const): (WebCore::Page::throttlingReasons const): (WebCore::Page::canUpdateThrottlingReason const): * page/RenderingUpdateScheduler.cpp: (WebCore::RenderingUpdateScheduler::setPreferredFramesPerSecond): (WebCore::RenderingUpdateScheduler::scheduleAnimation): (WebCore::RenderingUpdateScheduler::adjustRenderingUpdateFrequency): Change the preferredFramesPerSecond of the DisplayRefreshMonitor if the throttling is not aggressive e.g. 10_s. Otherwise use the timer. (WebCore::RenderingUpdateScheduler::scheduleTimedRenderingUpdate): Call adjustFramesPerSecond() when DisplayRefreshMonitor is created. (WebCore::RenderingUpdateScheduler::startTimer): * page/RenderingUpdateScheduler.h: * platform/graphics/AnimationFrameRate.h: Added. (WebCore::preferredFrameInterval): (WebCore::preferredFramesPerSecond): (WebCore::operator<<): Push names of ThrottlingReasons to a TextStream. * platform/graphics/DisplayRefreshMonitor.h: (WebCore::DisplayRefreshMonitor::setPreferredFramesPerSecond): * platform/graphics/DisplayRefreshMonitorManager.cpp: (WebCore::DisplayRefreshMonitorManager::monitorForClient): Rename createMonitorForClient() to monitorForClient() since it may return a cached DisplayRefreshMonitor. (WebCore::DisplayRefreshMonitorManager::setPreferredFramesPerSecond): (WebCore::DisplayRefreshMonitorManager::scheduleAnimation): (WebCore::DisplayRefreshMonitorManager::windowScreenDidChange): No need to call registerClient(). This function was just ensuring the DisplayRefreshMonitor is created. scheduleAnimation() does the same thing. (WebCore::DisplayRefreshMonitorManager::createMonitorForClient): Deleted. (WebCore::DisplayRefreshMonitorManager::registerClient): Deleted. * platform/graphics/DisplayRefreshMonitorManager.h: (WebCore::DisplayRefreshMonitorManager::DisplayRefreshMonitorManager): Deleted. * platform/graphics/GraphicsLayerUpdater.cpp: (WebCore::GraphicsLayerUpdater::GraphicsLayerUpdater): * platform/graphics/ios/DisplayRefreshMonitorIOS.mm: (-[WebDisplayLinkHandler setPreferredFramesPerSecond:]): Set the preferredFramesPerSecond of the CADisplayLink. * testing/Internals.cpp: (WebCore::Internals::requestAnimationFrameThrottlingReasons const): (WebCore::Internals::isRequestAnimationFrameThrottled const): Deleted. * testing/Internals.h: * testing/Internals.idl: Replace isRequestAnimationFrameThrottled() which returns a boolean by requestAnimationFrameThrottlingReasons() which returns a string. The string represents the throttling reasons. Source/WebKit: Create an IPC message on the DrawingArea to send a message from the WebProcess to the UIProcess to setPreferredFramesPerSecond of the DisplayRefreshMonitor. * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h: * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.messages.in: * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm: (-[WKOneShotDisplayLinkHandler setPreferredFramesPerSecond:]): (WebKit::RemoteLayerTreeDrawingAreaProxy::setPreferredFramesPerSecond): Set the preferredFramesPerSecond of the CADisplayLink. * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.h: * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.mm: (WebKit::RemoteLayerTreeDisplayRefreshMonitor::setPreferredFramesPerSecond): Forward the call to RemoteLayerTreeDrawingArea. * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h: * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::setPreferredFramesPerSecond): Send the IPC message from the WebProcess to the UIProcess. LayoutTests: * fast/animation/request-animation-frame-throttle-inside-overflow-scroll-expected.txt: * fast/animation/request-animation-frame-throttle-inside-overflow-scroll.html: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: * fast/animation/request-animation-frame-throttle-subframe-display-none.html: * fast/animation/request-animation-frame-throttle-subframe-expected.txt: * fast/animation/request-animation-frame-throttle-subframe-zero-size-expected.txt: * fast/animation/request-animation-frame-throttle-subframe-zero-size.html: * fast/animation/request-animation-frame-throttle-subframe.html: * fast/animation/request-animation-frame-throttling-detached-iframe-expected.txt: * fast/animation/request-animation-frame-throttling-detached-iframe.html: Replace the call isRequestAnimationFrameThrottled() by requestAnimationFrameThrottlingReasons(). * fast/animation/request-animation-frame-throttling-lowPowerMode-expected.txt: * fast/animation/request-animation-frame-throttling-lowPowerMode.html: Ensure the actual rAF interval is > 30ms for lowPowerMode. * http/tests/frame-throttling/raf-throttle-in-cross-origin-subframe-expected.txt: * http/tests/frame-throttling/raf-throttle-in-cross-origin-subframe.html: * http/tests/frame-throttling/resources/requestAnimationFrame-frame.html: Replace the call isRequestAnimationFrameThrottled() by requestAnimationFrameThrottlingReasons(). Canonical link: https://commits.webkit.org/224287@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@261113 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-05-04 21:24:49 +00:00
shouldBeEqualToString("testFrame.contentWindow.internals.requestAnimationFrameThrottlingReasons()", "[Unthrottled]");
Regression(183998): Disqus comments take a very long time to load https://bugs.webkit.org/show_bug.cgi?id=146522 <rdar://problem/21590601> Reviewed by Simon Fraser. Source/WebCore: Stop throttling requestAnimationFrame() in iframes that are not visible due to them being zero-sized or display:none. Those are usually utility iframes and throttling them is risky. Se still throttle requestAnimationFrame() in iframes that would be visible in theory but are currently not noticeable because they are outside the viewport. Test: - fast/animation/request-animation-frame-throttle-subframe.html - fast/animation/request-animation-frame-throttle-subframe-display-none.html - fast/animation/request-animation-frame-throttle-subframe-zero-size.html * page/FrameView.cpp: (WebCore::FrameView::updateScriptedAnimationsAndTimersThrottlingState): LayoutTests: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: * fast/animation/request-animation-frame-throttle-subframe-display-none.html: Update layout test as we changed behavior here. We no longer throttle display:none iframes. * fast/animation/request-animation-frame-throttle-subframe-zero-size-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe-zero-size.html: Added. Add layout test to check that we don't throttle RaF in iframes that are zero-sized. * fast/animation/resources/requestAnimationFrame-frame-2.html: * fast/animation/resources/requestAnimationFrame-frame.html: Update use of requestAnimationFrame() to be more representative of real world usage. Canonical link: https://commits.webkit.org/164609@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@186195 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-07-01 21:52:07 +00:00
finishJSTest();
Throttle RequestAnimationFrame in subframes that are outside the viewport https://bugs.webkit.org/show_bug.cgi?id=144718 <rdar://problem/20688782> Reviewed by Simon Fraser. Source/WebCore: Throttle RequestAnimationFrame in subframes that are outside the viewport or have "display: none" for performance and power. Tests: fast/animation/request-animation-frame-throttle-subframe-display-none.html fast/animation/request-animation-frame-throttle-subframe.html * dom/Document.h: (WebCore::Document::scriptedAnimationController): * dom/ScriptedAnimationController.cpp: (WebCore::ScriptedAnimationController::setThrottled): (WebCore::ScriptedAnimationController::isThrottled): * dom/ScriptedAnimationController.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::open): Call FrameView::setFrameRect() only *after* the view has been set on the Frame. Otherwise, setFrameRect() ends up calling viewportContentsChanged() and we hit the ASSERT(frame().view() == this) assertion in windowClipRect() because the Frame still has its old FrameView. This is covered by loader/go-back-to-different-window-size.html layout test. * page/FrameView.cpp: (WebCore::FrameView::viewportContentsChanged): (WebCore::FrameView::applyRecursivelyWithVisibleRect): (WebCore::FrameView::resumeVisibleImageAnimations): (WebCore::FrameView::updateScriptedAnimationsThrottlingState): (WebCore::FrameView::resumeVisibleImageAnimationsIncludingSubframes): (WebCore::FrameView::updateThrottledDOMTimersState): (WebCore::FrameView::scrollPositionChanged): Deleted. (WebCore::FrameView::sendResizeEventIfNeeded): Deleted. * page/FrameView.h: * testing/Internals.cpp: (WebCore::Internals::isRequestAnimationFrameThrottled): (WebCore::Internals::isTimerThrottled): Deleted. * testing/Internals.h: * testing/Internals.idl: LayoutTests: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe-display-none.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in "display: none" subframes. * fast/animation/request-animation-frame-throttle-subframe-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in frames that are outside the viewport. * fast/animation/resources/requestAnimationFrame-frame-2.html: Added. * fast/animation/resources/requestAnimationFrame-frame.html: Added. * platform/win/TestExpectations: Skip the 2 new tests on Windows as requestAnimationFrame throttling is only supported on Cocoa. Canonical link: https://commits.webkit.org/162829@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@183998 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-05-08 18:15:57 +00:00
}
</script>
Regression(183998): Disqus comments take a very long time to load https://bugs.webkit.org/show_bug.cgi?id=146522 <rdar://problem/21590601> Reviewed by Simon Fraser. Source/WebCore: Stop throttling requestAnimationFrame() in iframes that are not visible due to them being zero-sized or display:none. Those are usually utility iframes and throttling them is risky. Se still throttle requestAnimationFrame() in iframes that would be visible in theory but are currently not noticeable because they are outside the viewport. Test: - fast/animation/request-animation-frame-throttle-subframe.html - fast/animation/request-animation-frame-throttle-subframe-display-none.html - fast/animation/request-animation-frame-throttle-subframe-zero-size.html * page/FrameView.cpp: (WebCore::FrameView::updateScriptedAnimationsAndTimersThrottlingState): LayoutTests: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: * fast/animation/request-animation-frame-throttle-subframe-display-none.html: Update layout test as we changed behavior here. We no longer throttle display:none iframes. * fast/animation/request-animation-frame-throttle-subframe-zero-size-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe-zero-size.html: Added. Add layout test to check that we don't throttle RaF in iframes that are zero-sized. * fast/animation/resources/requestAnimationFrame-frame-2.html: * fast/animation/resources/requestAnimationFrame-frame.html: Update use of requestAnimationFrame() to be more representative of real world usage. Canonical link: https://commits.webkit.org/164609@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@186195 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-07-01 21:52:07 +00:00
<iframe id="testFrame" style="position: absolute; top: 800px; display: none;" src="resources/requestAnimationFrame-frame.html" onload="runTest()"></iframe>
Throttle RequestAnimationFrame in subframes that are outside the viewport https://bugs.webkit.org/show_bug.cgi?id=144718 <rdar://problem/20688782> Reviewed by Simon Fraser. Source/WebCore: Throttle RequestAnimationFrame in subframes that are outside the viewport or have "display: none" for performance and power. Tests: fast/animation/request-animation-frame-throttle-subframe-display-none.html fast/animation/request-animation-frame-throttle-subframe.html * dom/Document.h: (WebCore::Document::scriptedAnimationController): * dom/ScriptedAnimationController.cpp: (WebCore::ScriptedAnimationController::setThrottled): (WebCore::ScriptedAnimationController::isThrottled): * dom/ScriptedAnimationController.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::open): Call FrameView::setFrameRect() only *after* the view has been set on the Frame. Otherwise, setFrameRect() ends up calling viewportContentsChanged() and we hit the ASSERT(frame().view() == this) assertion in windowClipRect() because the Frame still has its old FrameView. This is covered by loader/go-back-to-different-window-size.html layout test. * page/FrameView.cpp: (WebCore::FrameView::viewportContentsChanged): (WebCore::FrameView::applyRecursivelyWithVisibleRect): (WebCore::FrameView::resumeVisibleImageAnimations): (WebCore::FrameView::updateScriptedAnimationsThrottlingState): (WebCore::FrameView::resumeVisibleImageAnimationsIncludingSubframes): (WebCore::FrameView::updateThrottledDOMTimersState): (WebCore::FrameView::scrollPositionChanged): Deleted. (WebCore::FrameView::sendResizeEventIfNeeded): Deleted. * page/FrameView.h: * testing/Internals.cpp: (WebCore::Internals::isRequestAnimationFrameThrottled): (WebCore::Internals::isTimerThrottled): Deleted. * testing/Internals.h: * testing/Internals.idl: LayoutTests: * fast/animation/request-animation-frame-throttle-subframe-display-none-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe-display-none.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in "display: none" subframes. * fast/animation/request-animation-frame-throttle-subframe-expected.txt: Added. * fast/animation/request-animation-frame-throttle-subframe.html: Added. Add layout test to test that RequestAnimationFrame is properly throttled in frames that are outside the viewport. * fast/animation/resources/requestAnimationFrame-frame-2.html: Added. * fast/animation/resources/requestAnimationFrame-frame.html: Added. * platform/win/TestExpectations: Skip the 2 new tests on Windows as requestAnimationFrame throttling is only supported on Cocoa. Canonical link: https://commits.webkit.org/162829@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@183998 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-05-08 18:15:57 +00:00
<script src="../../resources/js-test-post.js"></script>
</body>
</html>