Bug 114179
| Summary: | [CSS Filters] Add automated regression test for CA filter animation | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Max Vujovic <mvujovic> |
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | achicu, krit, simon.fraser |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 68469, 109098 | ||
Max Vujovic
smfr provided a manual test case in bug 114067, which we should automate and check in. He used the test case to find a regression caused by the patch in bug 109098.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Max Vujovic
An API to dump the current accelerated animations on a platform layer could be a good way to test this.
I looked at using the Internals::pauseTransitionAtTimeOnElement API to take a snapshot in the middle of an accelerated animation, but it looks like it fast-forwards the animation to the desired time and then does a style recalculation. I don't think this would catch the kind of regression that occurred in bug 114067, where the start state and end state were fine but the accelerated animation didn't run.
See AnimationControllerPrivate::pauseAnimationAtTime...
if (compAnim->pauseAnimationAtTime(name, t)) {
renderer->node()->setNeedsStyleRecalc(SyntheticStyleChange);
startUpdateStyleIfNeededDispatcher();
return true;
}