nephele
/
haikuwebkit
1
0
Fork 0
Code Issues Releases Activity
haikuwebkit/LayoutTests/compositing/backing/animate-into-view.html

87 lines
2.6 KiB
HTML
Raw Permalink Normal View History

REGRESSION (r233268): Elements animated in from offscreen sometimes don't display https://bugs.webkit.org/show_bug.cgi?id=192725 rdar://problem/46011418 Reviewed by Antoine Quint. Source/WebCore: There were two problems with backing store attachment and animation. First, animations are an input into the "backing store attached" logic, so when they change we should set the CoverageRectChanged bit on GraphicsLayerCA. Secondly, when an ancestor has unknown animation extent, all its descendants need to get backing store, so we need to set childCommitState.ancestorWithTransformAnimationIntersectsCoverageRect when the current layer has no animation extent. Tests: compositing/backing/animate-into-view-with-descendant.html compositing/backing/animate-into-view.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::addAnimation): (WebCore::GraphicsLayerCA::removeAnimation): (WebCore::GraphicsLayerCA::recursiveCommitChanges): LayoutTests: * compositing/backing/animate-into-view-expected.txt: Added. * compositing/backing/animate-into-view-with-descendant-expected.txt: Added. * compositing/backing/animate-into-view-with-descendant.html: Added. * compositing/backing/animate-into-view.html: Added. * platform/ios/compositing/backing/animate-into-view-expected.txt: Added. * platform/ios/compositing/backing/animate-into-view-with-descendant-expected.txt: Added. Canonical link: https://commits.webkit.org/207329@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239268 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-12-17 17:10:44 +00:00
<!DOCTYPE html>
<html>
<head>
<style>
.wrapper {
position: relative;
margin-top: 10px;
margin-left: -50px;
width: 952px;
height: 82px;
border: 1px solid black;
perspective: 2000px;
}
.middle {
position: absolute;
top: 15px;
left: 544px;
width: 9px;
height: 31px;
}
.letter {
top: 0px;
left: 0px;
width: 9px;
height: 31px;
position: absolute;
background-color: blue;
animation-fill-mode: forwards;
animation-duration: 3s;
animation-name: bounce;
}
.animating {
animation-name: bounce;
}
@keyframes bounce {
0% { transform: matrix3d(1.5, 0, 0, 0, 0, 0.5, 0, 0, 0, 0, 1, 0, -565.25, 7.75, 0, 1); }
19% { transform: matrix3d(1.5, 0, 0, 0, 0, 0.5, 0, 0, 0, 0, 1, 0, -565.25, 7.75, 0, 1); }
25% { transform: matrix3d(1.1558, 0, 0, 0, -0.00666, 0.7771, 0, 0, 0, 0, 1, 0, -504.006, -41.6730, 0, 1); }
47% { transform: matrix3d(1.5, 0, 0, 0, 0, 0.5, 0, 0, 0, 0, 1, 0, -283.75, 7.75, 0, 1); }
60% { transform: matrix3d(1.3906, 0, 0, 0, 0.073394, 0.6825, 0, 0, 0, 0, 1, 0, -143.645, 4.920146, 0, 1); }
89% { transform: matrix3d(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1); }
100% { transform: matrix3d(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1); }
}
</style>
<script>
if (window.testRunner) {
testRunner.dumpAsText();
testRunner.waitUntilDone();
}
function dumpLayers()
{
var layersResult = document.getElementById('layers');
if (window.testRunner)
layersResult.innerText = window.internals.layerTreeAsText(document, internals.LAYER_TREE_INCLUDES_BACKING_STORE_ATTACHED);
}
window.addEventListener('load', () => {
[Web Animations] Ensure CSS Transition and CSS Animation events are queued, sorted and dispatched by their timeline https://bugs.webkit.org/show_bug.cgi?id=207364 <rdar://problem/59370413> Reviewed by Simon Fraser. LayoutTests/imported/w3c: There are some progressions but also some "regressions". The progressions are real, showing the delivery of all animation events at the correct time. However, the regressions are misleading. The fact that the "style change" tests would work was due to a design issue in the test which would only wait one frame to detect whether a CSS Transition was started after a change made through the Web Animations API. These would work because events were queued in the next frame, but delivered later due to the dedicated per-animation queue used, which meant the test was fooled into thinking the CSS Transition did not start, as expected. Changing those test to use more than one frame to test for the lack of a CSS Transition would have shown the FAIL results. However, in order to not regress our WPT score, the issue of "style change" events will be addressed in a follow-up patch. * web-platform-tests/css/css-transitions/CSSTransition-startTime.tentative-expected.txt: * web-platform-tests/web-animations/interfaces/Animatable/animate-expected.txt: * web-platform-tests/web-animations/interfaces/Animation/style-change-events-expected.txt: * web-platform-tests/web-animations/interfaces/KeyframeEffect/style-change-events-expected.txt: * web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt: Source/WebCore: Until now, AnimationPlaybackEvent events, which are new events introduced by the Web Animations spec, were enqueued in a shared queue on the DocumentTimeline and dispatched during the "update animations and send events" procedure. However, AnimationEvent and TransitionEvent events, dispatched by CSS Animations and CSS Transitions, were dispatched via a dedicated per-animation queue, which meant typically that those events were dispathed one runloop after the AnimationPlaybackEvent events. We now remove the dedicated per-animation queue and enqueue all events in the shared DocumentTimeline queue for dispatch during the "update animations and send events" procedure. To do this correctly, we need to do a couple of other things that ensure we don't regress tests. First, we update the DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState() to account for whether there are pending animation events, guaranteeing that an animation update is scheduled should there be any. Second, when animation events are enqueued in DocumentTimeline::enqueueAnimationEvent() we schedule an animation update if needed, since we know we now have pending events that will need to be delivered in an upcoming update. We also maintain a flag between the start of the "update animations and send events" procedure and the moment when the pending animation events queue is cleared prior to dispatching events so that events enqueued in the meantime do not prematurely schedule animation resolution. The need for a new animation resolution will be checked at the end of the procedure. Finally, declarative animations used to have a special suclass of WebAnimation::needsTick() that would check whether they had any pending events, ensuring they would not be removed prematurely. We now reset a flag to false as WebAnimation::tick() is called (as part of the "update animations and send events" procedure) and set it to true in case an animation is enqueued. This flag is then used in needsTick() to guarantee the animation is not removed before the DocumentTimeline has had a chance to dispatch the enqueued event. Note also that, for clarity, the DocumentTimeline::unscheduleAnimationResolution() was renamed to DocumentTimeline::clearTickScheduleTimer() since it wouldn't actually cancel a previous animation resolution schedule. * animation/CSSTransition.h: Fix a newly found build error due to the missing wtf/MonotonicTime.h header. * animation/DeclarativeAnimation.cpp: Remove all code related to the dedicated per-animation queue and instead call the new WebAnimation::enqueueAnimationEvent() method to enqueue events on the DocumentTimeline. (WebCore::DeclarativeAnimation::DeclarativeAnimation): (WebCore::DeclarativeAnimation::tick): (WebCore::DeclarativeAnimation::enqueueDOMEvent): * animation/DeclarativeAnimation.h: * animation/DocumentTimeline.cpp: (WebCore::DocumentTimeline::detachFromDocument): Ensure the pending events queue is cleared when the timeline is detached from a document, ensuring that there no longer events that would cause a ref-cycle (DocumentTimeline -> AnimationPlaybackEvent -> WebAnimation -> DocumentTimeline). (WebCore::DocumentTimeline::suspendAnimations): (WebCore::DocumentTimeline::removeAnimation): (WebCore::DocumentTimeline::scheduleAnimationResolution): (WebCore::DocumentTimeline::clearTickScheduleTimer): (WebCore::DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState const): (WebCore::DocumentTimeline::updateCurrentTime): (WebCore::DocumentTimeline::updateAnimationsAndSendEvents): (WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents): (WebCore::DocumentTimeline::scheduleNextTick): (WebCore::DocumentTimeline::animationAcceleratedRunningStateDidChange): (WebCore::DocumentTimeline::enqueueAnimationEvent): * animation/DocumentTimeline.h: * animation/WebAnimation.cpp: (WebCore::WebAnimation::enqueueAnimationPlaybackEvent): (WebCore::WebAnimation::enqueueAnimationEvent): (WebCore::WebAnimation::needsTick const): (WebCore::WebAnimation::tick): * animation/WebAnimation.h: LayoutTests: Fix a couple of tests that made some incorrect assumptions. * TestExpectations: imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html is no longer flaky. * compositing/backing/animate-into-view.html: Because the "animationstart" event is now dispatched during the "update animations and send events" procedure, which happens during page rendering _before_ rAF callbacks are serviced, we must remove the rAF callback used prior to adding the "animationstart" event listener or else we would never get it and the test would time out. * webanimations/css-transition-in-flight-reversal-accelerated.html: We must wait for the initial transition to start and then two frames before reversing the transition, to be certain that the animation did start. Indeed, the "transitionstart" event will be fired right before the next rAF callback is called, as the animation starts in that very same frame, and so progress will be 0 and the transition wouldn't be reversable until the next frame when the animation has progress > 0. Canonical link: https://commits.webkit.org/220724@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256619 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-02-14 17:52:07 +00:00
let animator = document.getElementById('target');
animator.addEventListener('animationstart', () => {
requestAnimationFrame(() => {
dumpLayers();
if (window.testRunner)
testRunner.notifyDone();
REGRESSION (r233268): Elements animated in from offscreen sometimes don't display https://bugs.webkit.org/show_bug.cgi?id=192725 rdar://problem/46011418 Reviewed by Antoine Quint. Source/WebCore: There were two problems with backing store attachment and animation. First, animations are an input into the "backing store attached" logic, so when they change we should set the CoverageRectChanged bit on GraphicsLayerCA. Secondly, when an ancestor has unknown animation extent, all its descendants need to get backing store, so we need to set childCommitState.ancestorWithTransformAnimationIntersectsCoverageRect when the current layer has no animation extent. Tests: compositing/backing/animate-into-view-with-descendant.html compositing/backing/animate-into-view.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::addAnimation): (WebCore::GraphicsLayerCA::removeAnimation): (WebCore::GraphicsLayerCA::recursiveCommitChanges): LayoutTests: * compositing/backing/animate-into-view-expected.txt: Added. * compositing/backing/animate-into-view-with-descendant-expected.txt: Added. * compositing/backing/animate-into-view-with-descendant.html: Added. * compositing/backing/animate-into-view.html: Added. * platform/ios/compositing/backing/animate-into-view-expected.txt: Added. * platform/ios/compositing/backing/animate-into-view-with-descendant-expected.txt: Added. Canonical link: https://commits.webkit.org/207329@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239268 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-12-17 17:10:44 +00:00
});
});
[Web Animations] Ensure CSS Transition and CSS Animation events are queued, sorted and dispatched by their timeline https://bugs.webkit.org/show_bug.cgi?id=207364 <rdar://problem/59370413> Reviewed by Simon Fraser. LayoutTests/imported/w3c: There are some progressions but also some "regressions". The progressions are real, showing the delivery of all animation events at the correct time. However, the regressions are misleading. The fact that the "style change" tests would work was due to a design issue in the test which would only wait one frame to detect whether a CSS Transition was started after a change made through the Web Animations API. These would work because events were queued in the next frame, but delivered later due to the dedicated per-animation queue used, which meant the test was fooled into thinking the CSS Transition did not start, as expected. Changing those test to use more than one frame to test for the lack of a CSS Transition would have shown the FAIL results. However, in order to not regress our WPT score, the issue of "style change" events will be addressed in a follow-up patch. * web-platform-tests/css/css-transitions/CSSTransition-startTime.tentative-expected.txt: * web-platform-tests/web-animations/interfaces/Animatable/animate-expected.txt: * web-platform-tests/web-animations/interfaces/Animation/style-change-events-expected.txt: * web-platform-tests/web-animations/interfaces/KeyframeEffect/style-change-events-expected.txt: * web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt: Source/WebCore: Until now, AnimationPlaybackEvent events, which are new events introduced by the Web Animations spec, were enqueued in a shared queue on the DocumentTimeline and dispatched during the "update animations and send events" procedure. However, AnimationEvent and TransitionEvent events, dispatched by CSS Animations and CSS Transitions, were dispatched via a dedicated per-animation queue, which meant typically that those events were dispathed one runloop after the AnimationPlaybackEvent events. We now remove the dedicated per-animation queue and enqueue all events in the shared DocumentTimeline queue for dispatch during the "update animations and send events" procedure. To do this correctly, we need to do a couple of other things that ensure we don't regress tests. First, we update the DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState() to account for whether there are pending animation events, guaranteeing that an animation update is scheduled should there be any. Second, when animation events are enqueued in DocumentTimeline::enqueueAnimationEvent() we schedule an animation update if needed, since we know we now have pending events that will need to be delivered in an upcoming update. We also maintain a flag between the start of the "update animations and send events" procedure and the moment when the pending animation events queue is cleared prior to dispatching events so that events enqueued in the meantime do not prematurely schedule animation resolution. The need for a new animation resolution will be checked at the end of the procedure. Finally, declarative animations used to have a special suclass of WebAnimation::needsTick() that would check whether they had any pending events, ensuring they would not be removed prematurely. We now reset a flag to false as WebAnimation::tick() is called (as part of the "update animations and send events" procedure) and set it to true in case an animation is enqueued. This flag is then used in needsTick() to guarantee the animation is not removed before the DocumentTimeline has had a chance to dispatch the enqueued event. Note also that, for clarity, the DocumentTimeline::unscheduleAnimationResolution() was renamed to DocumentTimeline::clearTickScheduleTimer() since it wouldn't actually cancel a previous animation resolution schedule. * animation/CSSTransition.h: Fix a newly found build error due to the missing wtf/MonotonicTime.h header. * animation/DeclarativeAnimation.cpp: Remove all code related to the dedicated per-animation queue and instead call the new WebAnimation::enqueueAnimationEvent() method to enqueue events on the DocumentTimeline. (WebCore::DeclarativeAnimation::DeclarativeAnimation): (WebCore::DeclarativeAnimation::tick): (WebCore::DeclarativeAnimation::enqueueDOMEvent): * animation/DeclarativeAnimation.h: * animation/DocumentTimeline.cpp: (WebCore::DocumentTimeline::detachFromDocument): Ensure the pending events queue is cleared when the timeline is detached from a document, ensuring that there no longer events that would cause a ref-cycle (DocumentTimeline -> AnimationPlaybackEvent -> WebAnimation -> DocumentTimeline). (WebCore::DocumentTimeline::suspendAnimations): (WebCore::DocumentTimeline::removeAnimation): (WebCore::DocumentTimeline::scheduleAnimationResolution): (WebCore::DocumentTimeline::clearTickScheduleTimer): (WebCore::DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState const): (WebCore::DocumentTimeline::updateCurrentTime): (WebCore::DocumentTimeline::updateAnimationsAndSendEvents): (WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents): (WebCore::DocumentTimeline::scheduleNextTick): (WebCore::DocumentTimeline::animationAcceleratedRunningStateDidChange): (WebCore::DocumentTimeline::enqueueAnimationEvent): * animation/DocumentTimeline.h: * animation/WebAnimation.cpp: (WebCore::WebAnimation::enqueueAnimationPlaybackEvent): (WebCore::WebAnimation::enqueueAnimationEvent): (WebCore::WebAnimation::needsTick const): (WebCore::WebAnimation::tick): * animation/WebAnimation.h: LayoutTests: Fix a couple of tests that made some incorrect assumptions. * TestExpectations: imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html is no longer flaky. * compositing/backing/animate-into-view.html: Because the "animationstart" event is now dispatched during the "update animations and send events" procedure, which happens during page rendering _before_ rAF callbacks are serviced, we must remove the rAF callback used prior to adding the "animationstart" event listener or else we would never get it and the test would time out. * webanimations/css-transition-in-flight-reversal-accelerated.html: We must wait for the initial transition to start and then two frames before reversing the transition, to be certain that the animation did start. Indeed, the "transitionstart" event will be fired right before the next rAF callback is called, as the animation starts in that very same frame, and so progress will be 0 and the transition wouldn't be reversable until the next frame when the animation has progress > 0. Canonical link: https://commits.webkit.org/220724@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256619 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-02-14 17:52:07 +00:00
animator.classList.add('animating');
REGRESSION (r233268): Elements animated in from offscreen sometimes don't display https://bugs.webkit.org/show_bug.cgi?id=192725 rdar://problem/46011418 Reviewed by Antoine Quint. Source/WebCore: There were two problems with backing store attachment and animation. First, animations are an input into the "backing store attached" logic, so when they change we should set the CoverageRectChanged bit on GraphicsLayerCA. Secondly, when an ancestor has unknown animation extent, all its descendants need to get backing store, so we need to set childCommitState.ancestorWithTransformAnimationIntersectsCoverageRect when the current layer has no animation extent. Tests: compositing/backing/animate-into-view-with-descendant.html compositing/backing/animate-into-view.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::addAnimation): (WebCore::GraphicsLayerCA::removeAnimation): (WebCore::GraphicsLayerCA::recursiveCommitChanges): LayoutTests: * compositing/backing/animate-into-view-expected.txt: Added. * compositing/backing/animate-into-view-with-descendant-expected.txt: Added. * compositing/backing/animate-into-view-with-descendant.html: Added. * compositing/backing/animate-into-view.html: Added. * platform/ios/compositing/backing/animate-into-view-expected.txt: Added. * platform/ios/compositing/backing/animate-into-view-with-descendant-expected.txt: Added. Canonical link: https://commits.webkit.org/207329@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239268 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-12-17 17:10:44 +00:00
}, false);
</script>
</head>
<body>
<div class="wrapper">
<div class="middle">
<div id="target" class="letter">T</div>
</div>
</div>
<pre id="layers">Layer tree goes here in DRT</pre>
</body>
</html>