Bug 115278 - Flash of un-animated content
Summary: Flash of un-animated content
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.6
: P2 Normal
Assignee: Nobody
URL: http://jsfiddle.net/DFTzk/
Depends on:
Reported: 2013-04-26 14:31 PDT by Kevin Doughty
Modified: 2013-05-11 10:27 PDT (History)
4 users (show)

See Also:

Patch (1.81 KB, patch)
2013-05-09 16:00 PDT, Kevin Doughty
darin: review-
buildbot: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from webkit-ews-01 for mac-mountainlion (788.49 KB, application/zip)
2013-05-09 17:12 PDT, Build Bot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Doughty 2013-04-26 14:31:48 PDT
Flash of un-animatd content similar to rdar://problem/12081774 . A demo is at http://jsfiddle.net/DFTzk/ . I found this problem initially using Core Animation. It seems that even though an animation is added and the model value is set within the same transaction, there appears to be slight media timing differences. The workaround is to use kCAFillModeBoth, which ensures that there are no gaps.  The bug was not present in OSX 10.5 Leopard, I believe it was introduced when Core Animation was re-written in C++. Unfortunately CSS transactions do not allow fill mode to be specified, only CSS animations. The choice of component "WebCore Misc." was just a guess.
Comment 1 Kevin Doughty 2013-04-26 15:10:48 PDT
I know the problem is related to rdar://problem/12081774 because I wrote a framework that swizzles out CALayer and CAAnimation fillMode and setFillMode: to only allow kCAFillModeBoth. This obviously breaks lots of other stuff so I didn't upload it, but it does fix this bug. I wouldn't even know where to begin to create a patch.
Comment 2 Kevin Doughty 2013-05-09 16:00:26 PDT
Created attachment 201297 [details]
Comment 3 WebKit Commit Bot 2013-05-09 16:01:55 PDT
Attachment 201297 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCore/platform/graphics/ca/mac/PlatformCALayerMac.mm']" exit_code: 1
Source/WebCore/ChangeLog:5:  Line contains tab character.  [whitespace/tab] [5]
Source/WebCore/ChangeLog:6:  Line contains tab character.  [whitespace/tab] [5]
Source/WebCore/ChangeLog:7:  Line contains tab character.  [whitespace/tab] [5]
Source/WebCore/ChangeLog:12:  Line contains tab character.  [whitespace/tab] [5]
Total errors found: 4 in 2 files

If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 4 Kevin Doughty 2013-05-09 16:05:51 PDT
A better demo of this bug can be seen at http://jsfiddle.net/RndZs/
This was my first attempt at contributing to WebKit and creating a patch.
I encountered many difficulties while trying.
Comment 5 Kevin Doughty 2013-05-09 16:46:02 PDT
This is the best demo showing the bug, red is exposed in Safari for OSX:
Comment 6 Build Bot 2013-05-09 17:12:04 PDT
Comment on attachment 201297 [details]

Attachment 201297 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/280135

New failing tests:
Comment 7 Build Bot 2013-05-09 17:12:07 PDT
Created attachment 201304 [details]
Archive of layout-test-results from webkit-ews-01 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-01  Port: mac-mountainlion  Platform: Mac OS X 10.8.2
Comment 8 Darin Adler 2013-05-09 18:28:46 PDT
Comment on attachment 201297 [details]

View in context: https://bugs.webkit.org/attachment.cgi?id=201297&action=review

Thanks for tackling this.

Need to use spaces, not tabs. Doesn’t compile on Mac, need to find out why.

> Source/WebCore/platform/graphics/ca/mac/PlatformCALayerMac.mm:445
> +    // Workaround for <rdar://problem/7311367> flash of un-animated content <https://bugs.webkit.org/show_bug.cgi?id=115278>

Not a good WebKit comment. We need the comment to say briefly what this is working around and why this works.
Comment 9 Simon Fraser (smfr) 2013-05-10 13:40:54 PDT
I don't want to take this patch without further analysis of why the flash occurs. Just applying this bandaid is not a good idea.
Comment 10 Kevin Doughty 2013-05-11 10:27:18 PDT
I believe further analysis will show that this is the same as rdar://problem/12081774 , and that it is a Core Animation bug, not a WebKit one. For the radar, I uploaded a third regression that shows the bug but requires heavy GPU usage to trigger it. It is also available here: https://github.com/KevinDoughty/FlashOfUnAnimatedContent and the best web based test so far is here: http://jsfiddle.net/R6UW5/

The github repo shows that animations just do not start when expected every time. It quickly and repeatedly adds an animation with the same from and to value, so there should be no gaps without animation.

I hope you will permit me to continue to work on this regardless. It is a good learning experience for me. I would like to properly perform the test suites and submit a patch, because everything blew up last time. I will be sure to put a note in the ChangeLog that the patch should not to be accepted. (It is a good thing that it failed the first time because I left out a pretty important conditional to ensure that only CSS Transitions were given the fillMode.) However, this would show the effectiveness of the workaround and suggest that it is indeed related to the radar.