web-dev-qa-db-fra.com

Transition de transformation CSS saccadée dans Chrome

J'utilise la transformation CSS3 sur une image d'arrière-plan pour l'agrandir en survol.

J'ai testé dans les derniers navigateurs d'Opera, Safari et Firefox et je travaille bien et en douceur, cependant dans Chrome la transition est très saccadée.

Voici le lien, survolez les icônes sociales pour voir ce que je veux dire. http://www.media-flare.com/pins/ - J'ai remarqué que vous redimensionnez le navigateur sur mobile vue, ça empire.

J'ai fait une version jsfiddle ici et j'ai ralenti la transition car c'est plus difficile à voir.

http://jsfiddle.net/wsgfz/1/ - Cela semble saccadé dans chrome et firefox, lisse dans safari et opéra.

Puis-je faire quelque chose pour faciliter la transition?

Voici le code si vous ne pouvez pas voir 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>
css3css-transitionscss-transforms
23
Adam

Les transformations semblent mieux fonctionner que les transitions dans Chrome. Essaye ça:

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

L'effet de scintillement d'une entrée/sortie rapide de la souris devrait également disparaître.

21
user1467267

Mise à jour 2017

En réponse au message de @Matt Coughlin, les navigateurs qui prennent en charge nativement l'animation, rendent maintenant les animations CSS et JS sur leur propre thread ....

Les animations basées sur CSS et les animations Web, lorsqu'elles sont prises en charge en mode natif, sont généralement gérées sur un thread appelé "thread de compositeur". Ceci est différent du "fil principal" du navigateur, où le style, la mise en page, la peinture et JavaScript sont exécutés. Cela signifie que si le navigateur exécute des tâches coûteuses sur le thread principal, ces animations peuvent continuer sans être interrompues.

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

Ce document des développeurs prend également en charge la réponse actuellement acceptée de @ user1467267 ...

Dans la mesure du possible, vous devez éviter d'animer les propriétés qui déclenchent la mise en page ou la peinture. Pour la plupart des navigateurs modernes, cela signifie limiter les animations à l'opacité ou la transformation , les deux pouvant être hautement optimisées par le navigateur; peu importe que l'animation soit gérée par JavaScript ou CSS.

Le document suggère également de mettre en œuvre l'utilisation du will-change propriété de la propriété que vous animerez afin que le navigateur puisse effectuer des optimisations supplémentaires pour ces propriétés. Dans mon expérience personnelle, cela ne semble être visible que dans chrome pour l'opacité et la transformation.

element{
  will-change: transform, opacity;
}
17
Zze

Question fondamentale

Lorsqu'une animation s'exécute lentement et semble inégale, elle expose simplement les limites du navigateur qui sont toujours là.

Les navigateurs n'ont pas de fil dédié pour le rendu des animations. Les animations doivent rivaliser avec d'autres activités du navigateur comme les événements d'interface utilisateur. Et parfois, le navigateur est également en concurrence avec d'autres logiciels exécutés sur l'ordinateur. De plus, l'accélération matérielle disponible pour les navigateurs est probablement quelque peu limitée.

Les animations avec accélération s'exécutent encore plus lentement au début et/ou à la fin de l'animation, ce qui rend encore plus évidente l'inégalité naturelle des animations.

Solutions

La solution la plus simple pour éviter que les irrégularités ne soient si évidentes consiste à augmenter la vitesse de l'animation et éventuellement à supprimer ou à réduire l'utilisation de l'assouplissement. Il peut être possible d'utiliser un type d'accélération qui ne ralentit pas autant au début et à la fin.

À l'avenir, une autre option consiste à utiliser l'accélération matérielle de WebGL (balise canvas HTML5 avec un contexte 3D), ce qui devrait atténuer le problème. À mesure que l'accélération matérielle devient plus courante et mieux prise en charge sur les navigateurs et les appareils, il devrait être possible de créer des animations complexes qui fonctionnent aussi bien que les anciennes animations Flash.

13
Matt Coughlin