Prevent Flicker on Webkit-Transition of Webkit-Transform

@keyframes spin {  100% {    transform: rotateX(360deg);  }}
ul {  display: flex;  flex-direction: column;  align-items: flex-start;}
li:hover {  cursor: pointer;}
a:focus,li:hover a {  animation: spin 0.9s 1 linear;}
ul a {  color: #000;  display: inline-block;  height: 50px;}
ul a:focus,ul li:hover a {  background-image: radial-gradient(ellipse at center, #777 0%, #222 100%);  color: #fff;}

<ul>  <li><a href="admin/">Admin</a></li>  <li><a href="appointments/">Appointments</a></li>  <li><a href="blog/">Blog</a></li>  <li><a href="calendar/">Calendar</a></li>  <li><a href="contact/">Contact</a></li>  <li><a href="events/">Events</a></li>  <li><a href="forms/">Forms</a></li>  <li><a href="forums/">Forums</a></li>  <li><a href="guestbook/">Guestbook</a></li>  <li><a href="mail/">Mail</a></li>  <li><a href="members/">Members</a></li>  <li><a href="newsletter/">Newsletter</a></li>  <li><a href="notifications/">Notifications</a></li>  <li><a href="search/">Search</a></li></ul>

Opacity change during a transition flickers in Safari

The problem is changing property values and adding animations need to happen at the same time.

A race condition not present in OSX 10.5 was introduced when Core Animation was rewritten in C++. I learned this when my experiments with additive animation developed the same flicker. I found the workaround to be Core Animation's kCAFillModeBackwards. I also found the same workaround was effective for CSS Transitions by hacking up my own fork of WebKit, with emphasis on the hacking part. But conjecture doesn't help WebKit devs and I didn't want to annoy them any further. I do think the problem is with Core Animation, not WebKit. I'm guessing that they should use the same CFTimeInterval derived from a single call to CACurrentMediaTime throughout any given CATransaction.

Unlike transitions, CSS animations do allow for fill modes. It might be difficult to reproduce transition behavior, but that is one option. In particular, the challenge would be replacing interrupted animations with new ones that begin where the previous left off. In other words, it's easy to animate from opacity of 0 to 1 or 1 to 0, but what happens if the user wants to start when current animated progress is at 0.577564? This might require manually modifying the @keyframes style rule, not an easy task.

Then there is the question of the appropriate animation-fill-mode. Normally you wouldn't want to perform layout using forward filling animations, you'd use the CSS properties themselves. But in this case it might be simple enough to not set the underlying value, instead use only a forward filling CSS animation that gets replaced but never removed when finished. The alternative is setting the underlying value via element.style and at the same time adding a backwards filling CSS animation.

Of course, the flicker also does not happen if WebKit doesn't use Core Animation. By far the easiest way to prevent the flicker in your case is to not enable hardware acceleration.

Instead of:

-webkit-transform: translate3d(100px, 100px, 0);

try:

-webkit-transform: translate(100px, 100px);

http://jsfiddle.net/z6ejt/9/

CSS Transform causes flicker in Safari, but only when the browser is = 2000px wide

Frustrating huh?

See EDIT4 for the answer to why 2000px is a magic number.

There is a couple of things you can try.

• Add -webkit-transform-style: preserve-3d; to the elements that are
  flickering.

• add -webkit-backface-visibility: hidden; to the elements that are
  
  flickering.

• move the animating element outside of the parent the flickering
  
  elements are within.

EDIT —
Wesley Hales, said here
"I encountered glitchy behaviour when applying hardware acceleration to parts of the page that were already accelerated"

Its hard to help you debug this without any code. But for starters I suggest you turn on debug mode in safari. Write 'defaults write com.apple.Safari IncludeInternalDebugMenu -bool true' in the terminal.

After this a Debug menu will show up. Choose Drawing/Compositing flags > Show Compositing borders.

This will help you see whats being rendered and by that choose what to put in hardware acceleration and what to leave out.

EDIT2 —
This is worth checking out as well: fast-animation-with-ios-webkit

Its regarding iOs, but I've experienced that - in some circumstances - solutions that work on iOs also works on osx.

EDIT3 —
If you are just asking what happens when its bigger than 2000px I can tell you for sure that on iPhones, WebKit creates textures that are no larger than 1024 by 1024, and if your element is larger than that, it has to create multiple textures.

Documentation on texture limitations

Now, when they do it on iPhone, it wouldn't surprise me if they do the same on OsX, but has a higher limit.

Don't know if this is your case tho. Impossible to tell without any code.

EDIT4 —
"The implementation in TextureMapperTiledBackingStore is pretty simple, and is used only to work around the 2000x2000 texture size limitation in OpenGL."

So, if your element is bigger than 2000x2000 it has to create multiple textures.

http://trac.webkit.org/wiki/CoordinatedGraphicsSystem

Related Topics