css3 - transiciones - Transferencia de la transformación de CSS en desigual en Chrome

transition css hover

Question

Estoy utilizando la transformación CSS3 en una imagen de fondo para ampliarla al pasar el cursor.

He probado en los últimos navegadores de Opera, Safari y Firefox y funciona bien y sin problemas, sin embargo, en Chrome la transición es muy desigual.

Aquí está el enlace, pase el cursor sobre los íconos sociales para ver a qué me refiero ... http://www.media-flare.com/pins/ - He notado que a medida que cambia el tamaño del navegador a la vista móvil, se pone peor.

He hecho una versión de jsfiddle aquí y he ralentizado la transición, ya que es más difícil de ver.

http://jsfiddle.net/wsgfz/1/ - Esto parece desigual en chrome y firefox, suave en safari y opera.

¿Hay algo que pueda hacer para que la transición sea más fácil?

Aquí está el código si no puede ver jsfiddle

HTML

<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>

CSS

.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);
 }

Answer 1

Las transformaciones parecen funcionar mejor que las transiciones en Chrome. Prueba esto:

.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>

El efecto parpadeante de un mouse rápido de entrada / salida debería desaparecer también ahora.

Answer 2

Actualización 2017

En respuesta a la publicación de @Matt Coughlin, los navegadores que admiten la animación de forma nativa, ahora representan las animaciones CSS y JS en su propio hilo ...

Las animaciones basadas en CSS, y las animaciones web donde se admiten de forma nativa, normalmente se manejan en un hilo conocido como "hilo compositor". Esto es diferente del "hilo principal" del navegador, donde se ejecutan el estilo, el diseño, la pintura y JavaScript. Esto significa que si el navegador ejecuta algunas tareas costosas en el hilo principal, estas animaciones pueden continuar sin ser interrumpidas.

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

Este documento para desarrolladores también admite la respuesta actualmente aceptada de @ user1467267 ...

Donde pueda, debe evitar las propiedades de animación que activan el diseño o la pintura. Para la mayoría de los navegadores modernos, esto significa limitar las animaciones a la opacidad o la transformación , las cuales el navegador puede optimizar altamente; no importa si la animación es manejada por JavaScript o CSS.

El documento también sugiere implementar el uso de la propiedad will-change para la propiedad que animará para que el navegador pueda realizar optimizaciones adicionales para estas propiedades. En mi experiencia personal, esto solo parece ser notable en el cromo para la opacidad y la transformación.

element{
  will-change: transform, opacity;
}

Answer 3

Cuestión fundamental

Cuando una animación se ejecuta lentamente y se ve desigual, simplemente se exponen las limitaciones del navegador que siempre están ahí.

Los navegadores no tienen un hilo dedicado para renderizar animaciones. Las animaciones tienen que competir con otras actividades del navegador como los eventos de IU. Y a veces el navegador también compite con otro software que se ejecuta en la computadora. Además, la aceleración de hardware disponible para los navegadores es probablemente algo limitada.

Las animaciones con atenuación se ejecutan incluso más lentamente al comienzo y / o al final de la animación, lo que hace que el desnivel natural de las animaciones sea aún más evidente.

Soluciones

La solución más simple para evitar que la irregularidad sea tan obvia es aumentar la velocidad de la animación y, opcionalmente, eliminar o disminuir el uso de la flexibilización. Puede ser posible usar un tipo de alivio que no se ralentice tanto al principio y al final.

En el futuro, otra opción es utilizar la aceleración de hardware de WebGL (etiqueta de lienzo HTML5 con un contexto 3D), lo que debería disminuir el problema. A medida que la aceleración de hardware se vuelve más común y mejor admitida en navegadores y dispositivos, debería ser factible realizar animaciones complejas que se ejecuten tan bien como las animaciones Flash más antiguas.