27

I am using CSS3 transform on a background image to enlarge on hover.

I have tested in the latest browsers of Opera, Safari and Firefox and work nice and smooth, however in Chrome the transition is very jerky.

Heres is the link, hover over the social icons to see what I mean.. http://www.media-flare.com/pins/ - I have noticed as you resize the browser down to mobile view, it gets worse.

I have done a jsfiddle version here and slowed down the transition as it is harder to see.

http://jsfiddle.net/wsgfz/1/ - This seems jerky in chrome and firefox, smooth in safari and opera.

Is there anything I can do to make the transition smoother?

Here is the code if you cannot view jsfiddle

.social {
   position: relative;
   list-style:none;
}

.social > li > a {
   text-indent: 100%;
   white-space: nowrap;
   overflow: hidden;
   color: transparent;
}

.social > li > a {
   text-indent: 100%;
   white-space: nowrap;
   overflow: hidden;
   color: transparent;
}

.fbook, .twit, .tmblr, .pntrst, .insta {
   background: url(http://placehold.it/350x150) center center;
   width: 78px;
   height: 90px;
   background-size: cover;
   float: left;
   margin: 30px;
   -webkit-transition: all 0.8s ease;
   -moz-transition: all 0.8s ease;
   transition: all 0.8s ease;
 }

 .fbook {background-position: 0 0}
 .twit {background-position: -78px 0}
 .tmblr {background-position: -156px 0}
 .pntrst {background-position: -232px 0}
 .insta {background-position: -310px 0}

.fbook:hover, .twit:hover, .tmblr:hover, .pntrst:hover, .insta:hover {
    -webkit-transform: scale(1.5);
    -moz-transform: scale(1.5);
    transform: scale(1.5);
 }
<ul class="social">
  <li><a href="" class="fbook">Facebook</a></li>
  <li><a href="" class="twit">Twitter</a></li>
  <li><a href="" class="tmblr">Tumbler</a></li>
  <li><a href="" class="pntrst">Pinterest</a></li>
  <li><a href="" class="insta">Instagram</a></li>
  <li><a href="" class="rss">RSS</a></li>
</ul>
Adam
  • 1,341
  • 8
  • 28
  • 45

3 Answers3

23

Update 2017

In response to @Matt Coughlin's post, browsers that natively support animation, now render CSS and JS animations on their own thread....

CSS-based animations, and Web Animations where supported natively, are typically handled on a thread known as the "compositor thread." This is different from the browser's "main thread", where styling, layout, painting, and JavaScript are executed. This means that if the browser is running some expensive tasks on the main thread, these animations can keep going without being interrupted.

https://developers.google.com/web/fundamentals/design-and-ui/animations/animations-and-performance

This developers doc also supports the currently accepted answer from @user1467267...

Where you can, you should avoid animating properties that trigger layout or paint. For most modern browsers, this means limiting animations to opacity or transform, both of which the browser can highly optimize; it doesn’t matter if the animation is handled by JavaScript or CSS.

The document also suggests implementing the use of the will-change property for the property which you will be animating so that the browser can perform additional optimisations for these properties. In my personal experience, this only seems to be noticeable in chrome for opacity and transform.

element{
  will-change: transform, opacity;
}
Zze
  • 15,599
  • 9
  • 68
  • 98
22

Transformations seem to work better than transitions in Chrome. Try this:

.social {
  position: relative;
  list-style: none;
}
.social > li > a {
  text-indent: 100%;
  white-space: nowrap;
  overflow: hidden;
  color: transparent;
}
.social > li > a {
  text-indent: 100%;
  white-space: nowrap;
  overflow: hidden;
  color: transparent;
}
.fbook,
.twit,
.tmblr,
.pntrst,
.insta {
  background: url(http://placehold.it/350x150) center center;
  width: 78px;
  height: 90px;
  background-size: cover;
  float: left;
  margin: 30px;
  -webkit-transform: translate(0px, 0);
  -webkit-transition: -webkit-transform 0.8s ease;
  -moz-transform: translate(0px, 0);
  -moz-transition: -moz-transform 0.8s ease;
  transform: translate(0px, 0);
  transition: -webkit-transform 0.8s ease;
}
.fbook {
  background-position: 0 0
}
.twit {
  background-position: -78px 0
}
.tmblr {
  background-position: -156px 0
}
.pntrst {
  background-position: -232px 0
}
.insta {
  background-position: -310px 0
}
.fbook:hover,
.twit:hover,
.tmblr:hover,
.pntrst:hover,
.insta:hover {
  -webkit-transform: scale(1.5);
  -moz-transform: scale(1.5);
  transform: scale(1.5);
}
<ul class="social">
  <li><a href="" class="fbook">Facebook</a>
  </li>
  <li><a href="" class="twit">Twitter</a>
  </li>
  <li><a href="" class="tmblr">Tumbler</a>
  </li>
  <li><a href="" class="pntrst">Pinterest</a>
  </li>
  <li><a href="" class="insta">Instagram</a>
  </li>
  <li><a href="" class="rss">RSS</a>
  </li>
</ul>

The flickering effect one quick mouse in/out should be gone too now.

brandito
  • 646
  • 7
  • 19
16

Fundamental issue

When an animation runs slowly and looks uneven, it's simply exposing the limitations of the browser that are always there.

Browsers don't have a dedicated thread for rendering animations. Animations have to compete with other browser activities like UI events. And at times the browser is also competing with other software running on the computer. Plus the hardware acceleration available to browsers is likely somewhat limited.

Animations with easing run even slower at the start and/or end of the animation, which makes the natural unevenness of animations even more obvious.

Solutions

The simplest solution to prevent the unevenness from being so obvious is to increase the speed of the animation, and optionally remove or lessen the use of easing. It may be possible to use a type of easing that doesn't slow down quite as much at the beginning and end.

Going forward, another option is to use the hardware acceleration of WebGL (HTML5 canvas tag with a 3D context), which should lessen the issue. As hardware acceleration becomes more common and better-supported on browsers and devices, it should start to be feasible to make complex animations that run as smoothly as older Flash animations.

Matt Coughlin
  • 17,170
  • 3
  • 42
  • 57
  • 34
    the question is, why don't animations have dedicated thread...why PC games from 15 years ago ran smoother graphics than a simple transition for some DIV in 2014... – vsync Jan 07 '14 at 13:10
  • 12
    @vsync that might have to do with the fact that HTML was supposed to be a text format, not interactive nor animated stuff, and browsers have to follow new specifications while still supporting 20-year-old documents. Games were built to be games. A bit of a oranges vs apples comparison. – fregante Jan 25 '15 at 20:37
  • 5
    This is not accurate. It varies from browser to browser, but properties like translate 3D are handled by the GPU. Choosing the right property to take advantage of the GPU is a huge part of optimizing CSS animations. – Perry Nov 30 '15 at 17:31
  • Could you please provide an example implementation of using canvas with a 3d context to improve css animations? – Bill Jan 15 '16 at 15:15
  • Canvas is a very "manual" approach. There is a reason why it's faster but it's much more difficult to implement than it most often is worth. The positioning of the canvas element alone can be a challenge when working the flow of the interface. – www139 Sep 18 '18 at 02:53