Bug 127087 - [Texmap] Intrinsic style should be set after the animation is done
Summary: [Texmap] Intrinsic style should be set after the animation is done
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Jae Hyun Park
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-16 01:31 PST by Jae Hyun Park
Modified: 2014-04-21 00:06 PDT (History)
8 users (show)

See Also:


Attachments
Patch (2.58 KB, patch)
2014-01-16 01:41 PST, Jae Hyun Park
no flags Details | Formatted Diff | Diff
Patch (3.71 KB, patch)
2014-01-20 17:45 PST, Jae Hyun Park
no flags Details | Formatted Diff | Diff
Patch (3.68 KB, patch)
2014-01-22 21:01 PST, Jae Hyun Park
noam: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jae Hyun Park 2014-01-16 01:31:39 PST
After keyframe animation is done, the div with the animation should go back to its intrinsic style.
However, current implementation in TextureMapperLayer makes the div to go back to the first keyframe style, and then to its intrinsic style.
The above description is more easily understood by the example below.
http://black.company100.com/test/bugs/animation.html
Comment 1 Jae Hyun Park 2014-01-16 01:41:16 PST
Created attachment 221346 [details]
Patch
Comment 2 Jae Hyun Park 2014-01-20 17:45:58 PST
Created attachment 221708 [details]
Patch
Comment 3 Jae Hyun Park 2014-01-22 21:01:28 PST
Created attachment 221943 [details]
Patch
Comment 4 Gwang Yoon Hwang 2014-01-22 22:03:20 PST
I think this patch is okay.

What I understand the original code is trying to apply intrinsic styles to layers after the end of the animation. And the problem is we cannot know the exact intrinsic style of the layer at TextureMapperLayer.

Since the computed value will be updated from GraphicsLayer after the end of the animation, we do not need to assume(?) intrinsic style of the layer without active animations in TextureMapperLayer::syncAnimations().
Comment 5 Noam Rosenthal 2014-01-23 04:11:32 PST
Comment on attachment 221943 [details]
Patch

Needs test.
Comment 6 Jae Hyun Park 2014-01-23 05:24:47 PST
(In reply to comment #5)
> (From update of attachment 221943 [details])
> Needs test.

It's pretty hard to make a test case for this, because it is a timing issue.

If TextureMapperLayer::syncAnimations() was called when the animation was at StoppedState, it will apply the style of the first keyframe animation. Then, the intrinsic style of the element will be set via TextureMapperLayer::setTransform/Opacity/Filters and the animation will be removed. So, when the next syncAnimations() is called, the intrinsic style of the element is applied.

However, in most cases, when animation is at StoppedState, the intrinsic style of the element is set immediately via TextureMapperLayer::setTransform/Opacity/Filters and the animation is removed. 
So, when TextureMapperLayer::syncAnimations() is called, it will apply the intrinsic style of the element right away.

The problem is easily reproducible in slow devices, or if the javascript execution is frequent during the keyframe animation.

Do you have any suggestion on how to make a test case for such timing issue cases?
Comment 7 Hyowon Kim 2014-04-21 00:06:02 PDT
Hi, Jaehyun.
I'm looking forward to landing this patch.

Coordinated Graphics has a same flickering issue, which is to show up the first frame of css animation when the animation is at StoppedState.
It's easy to reproduce on the EFL MiniBrowser.
testcase: http://www.apple.com/html5/showcase/transitions/

I hope this patch is reviewed and applied. Thanks.