Zie ook hier:
Ik heb even snel een probleemreproducering gemaakt: http://jsfiddle.net/8nvHE/
Als je dus in Chrome naar een ander tabblad switcht en vervolgens na een paar seconde weer terug gaat, maakt de slider een inhaalslag, omdat Chrome t.b.v. de CPU animaties op niet actieve pagina's soort van pauzeert.
jQuery vertelt mij het volgende hierover:
- http://stackoverflow.com/...n-coming-from-another-tab
- http://stackoverflow.com/...tab-is-inactive-in-chrome
- http://stackoverflow.com/...ching-breaks-my-slideshow
Ik heb even snel een probleemreproducering gemaakt: http://jsfiddle.net/8nvHE/
Als je dus in Chrome naar een ander tabblad switcht en vervolgens na een paar seconde weer terug gaat, maakt de slider een inhaalslag, omdat Chrome t.b.v. de CPU animaties op niet actieve pagina's soort van pauzeert.
jQuery vertelt mij het volgende hierover:
Dat vetgedrukte gedeelte ^^ heb ik volgens mij toegepast in het bovenstaande voorbeeldje op jsfiddle. Waarom stapelen de animaties nu nog steeds op in de queue? Zie ik iets over het hoofd?Because of the nature of requestAnimationFrame(), you should never queue animations using a setInterval or setTimeout loop. In order to preserve CPU resources, browsers that support requestAnimationFrame will not update animations when the window/tab is not displayed. If you continue to queue animations via setInterval or setTimeout while animation is paused, all of the queued animations will begin playing when the window/tab regains focus. To avoid this potential problem, use the callback of your last animation in the loop, or append a function to the elements .queue() to set the timeout to start the next animation.