// Repaints the progress bar's filled-in amount based on the % of time elapsed for current video.
progressBar.change(function () {
var currentTime = $(this).val();
var totalTime = parseInt($(this).prop('max'), 10);
// Don't divide by 0.
var fill = totalTime !== 0 ? currentTime / totalTime : 0;
// EDIT: Added this check, testing with it now.
if (fill < 0 || fill > 1) throw "Wow this really should not have been " + fill;
var backgroundImage = '-webkit-gradient(linear,left top, right top, from(#ccc), color-stop(' + fill + ',#ccc), color-stop(' + fill + ',rgba(0,0,0,0)), to(rgba(0,0,0,0)))';
$(this).css('background-image', backgroundImage);
});
I'm filling a progress bar over time using the above javascript to modify its background-image with a gradient.Extremely intermittently -- the background image just entirely stops rendering. I've placed logging throughout this code and everything seems to be firing properly. I'm not dividing by 0, nor is my fill 0, but the background image stops showing up.If I reload the dom element -- it starts to work again! So, I'm wondering if I'm just doing something really wrong here. Maybe I can't set background-image like so continuously for hours?EDIT: I'm going to try and get a short video clip going with some logging to highlight the issue. It might take me a bit to reproduce.
I put a breakpoint into the code and observed the value of fill to be a value greater than 0 and less than 1. In this instance its value was 0.6925
Putting a breakpoint into the code, breaking on the point and then allowing execution to continue causes the progress bar's fill to re-appear!
EDIT2: Here's a video of it happening: http://screencast.com/t/DvzBr06f
4 Réponses :
Peut-être que vous pouvez éviter de changer le BG pour les granularités de <0,3%?
XXXEspérons s'il s'agit d'une question de ressource, 300 fois serait faisable - où 10 000 fois peut-être pas .
Non, il n'y a pas de limite. Vous pouvez modifier l'image autant que vous le souhaitez, bien qu'il puisse y avoir des problèmes concernant le cache et les ressources, maintenez donc la valeur dans les 10000.
Non, autant que je sache, il n'y a pas de limites. Et je ne pense pas que cela affecte vraiment quoi que ce soit du tout.
Veuillez vous expliquer votre réponse.
Il n'y a pas de limite. Quel navigateur utilisez-vous? Il peut y avoir quelques problèmes avec le cache de navigateur, alors essayez de ne pas trop changer l'image. Voici un test que j'ai mis ensemble, qui fonctionne bien, Fiddle et code:
CSS: < / p> html: js:
Merci pour l'exemple. Le problème est finalement parti, mais j'ai quitté cette question ouverte puisqu'il avait un nombre élevé de voix. La clôture maintenant avec le vôtre, car c'est la meilleure réponse.
Nope, il n'y a pas de limites au nombre de fois que vous pouvez changer une propriété CSS.
Bon à savoir. Merci.
Quelle est la valeur exacte de la variable remplir quand cela se produit? Ajoutez un autre chèque et voyez s'il est toujours déclenché
si (remplir <0 || remplissage> 1)Comme l'a déclaré Adeneo, il n'y a pas de limite au nombre de fois que vous pouvez changer d'image de fond, mais je dirais que cela ne changeait pas généralement à plusieurs reprises. Voyez-vous cela arriver dans plusieurs navigateurs?
Si vous essayez de mettre à jour quelque chose d'autre qu'un dégradé, vous obtiendrez toujours des arrêts? Dans quel (s) navigateur (s) testez-vous?
Je ne teste que dans les derniers canaux Dev et bêta de Google Chrome. Je vais essayer de mettre à jour cet article avec les informations demandées dans les divers commentaires. Donnez-moi quelques-uns.
Y a-t-il une raison pour laquelle vous interrogez constamment le DOM pour vos données? Ne l'avez-vous pas déjà attribué ailleurs dans votre code? Aussi, pourquoi vous reconstruisez-vous constamment votre gradient? Vous devriez plutôt utiliser un conteneur et redimensionner un DIV à l'intérieur.
J'ai fait un petit exemple pour démontrer ce que je veux dire mieux: jsfiddle.net/m2wup