2013-02-26 31 views
11

Questa domanda è simile nello spirito a questa altra domanda, ha chiesto due anni fa: Why does Raphael's framerate slow down on this code?Raphael: Graduale rallentamento animazione con semplice animazione infinita

sto usando Raphael 2.1.0 in cromo 25 nel seguente modo:

<html> 
<head> 
    <title>Drawfun</title> 
    <style> 
    * { 
     margin: 0; 
     padding: 0; 
    } 
    </style> 
</head> 
<body> 
    <script src="raphael.js"></script> 
    <script> 
    var paper = Raphael(10, 50, 320, 200); 
    var anim = Raphael.animation({transform: "R360"}, 500).repeat(Infinity); 

    var rect = paper.rect(50, 40, 10, 20); 
    rect.attr("fill", "#f00"); 
    rect.attr("stroke", "#fff"); 
    rect.animate(anim); 
    </script> 
</body> 
</html> 

Inizialmente, il rettangolo gira senza problemi, come ci si aspetterebbe. Dopo un minuto o due, la rotazione è in esecuzione a ~ 15 FPS. Dopo cinque o otto minuti, l'animazione è in esecuzione a ~ 5 FPS.

I profili CPU di Chrome indicano che, man mano che l'animazione diventa più irregolare, lo script trascorre sempre meno tempo in (program) e più e più volte in repush e eve.listeners.

Il Task Manager di Chrome non indica una perdita di memoria, nel pool di memoria JS o in Chrome, ma rivela che la pagina consuma sempre più CPU nel tempo.

Quando si esegue quella pagina in una versione recente di Firefox, l'animazione diventa molto più veloce, molto più rapidamente. Questi risultati sono stati verificati su Linux e Windows, quindi non è un problema del sistema operativo :).

Qualcuno ha qualche idea di ciò che potrebbe essere sbagliato nel mio codice o negli interni di Raphael?

+2

Dopo aver eseguito il codice in jsfiddle per 10 minuti utilizzando Chrome versione 25.0.1364.97 m, non sono stato in grado di notare la riduzione del frame rate, come sono stai misurando il frame rate? Puoi provare questo - http://jsfiddle.net/MEQRr/ – Neil

+0

l'ho visto girare sulla macchina di Kenneth, la riduzione del frame rate era drammatica, per niente sottile. Dopo dieci minuti sembrava approssimativamente 2 fotogrammi al secondo. –

+0

Dopo aver lasciato il tuo jsfiddle per un po 'ho sicuramente sperimentato un grande degrado nel framerate.Lo abbiamo testato su Chrome su Mac, Windows, Linux e Firefox su Linux. È stato presente in tutti i browser che abbiamo testato. Chrome 26.0.1410.12 dev. Sospetto che il degrado sarà meno pronunciato se la scheda è una scheda di sfondo e non una in primo piano. –

risposta

2

Ok, so che questa non è esattamente la risposta che qualcuno vuole sentire (ed è un discutibile cop-out), ma dallo sguardo di Raffaello, e la lettura dei commenti sopra, non posso aiutare ma pensa che questo sia un problema di garbage collection, ed è il motivo per cui i risultati variano nei browser di tutti. Da una rapida occhiata alla fonte di Raffaello, sembra che un bel po 'di vars siano dichiarati o implementati nel processo di animazione di un frame, per ogni frame. So per certo che almeno nel motore V8 di Chrome, ogni var è dichiarata in un metodo tracciabile e messa sullo heap, il ritardo nella riduzione framerate indica solo che il garbage collector sta dando il kick in modalità alta per liberare blocchi di ha dichiarato vars che non sono più in uso. Scommetterei un sacco di soldi che se dovessi spostare un sacco di dichiarazioni nella sceneggiatura di Raffaello in uno scope più elevato (forse anche globale, gasp ~!), In particolare durante le sequenze di animazione, troverai un frame-rate molto migliorato rispetto a il corso della sceneggiatura.

Mi sono imbattuto in questo problema su un'implementazione personalizzata di un adattamento a webgl, in pratica stavo facendo funzionare i comandi webgl senza abilitare webgl. Il rasterizzatore della pipeline che ho costruito ha avuto un problema molto simile a questo, in pratica avrebbe disegnato i frame a partire da 68fps, ma entro la fine del test sarebbe sceso a 13fps o inferiore e al 98% per l'utilizzo del processore. Non è stato fino a quando ho ripulito ogni singola dichiarazione che ha creato nuove allocazioni di memoria fuori dal campo di applicazione della pipeline (e ho fatto un po 'più di ricerca su trucchi che avevano a che fare con ricerche variabili) che ero finalmente in grado di tenere il passo e produrre un rasterizzatore ben scritto che potrebbe pompare circa 3-5 MB/s di pixel sullo schermo alla volta mantenendo una velocità di 50-60 fps.

Anche in questo caso, non sono sicuro se questa è la risposta desiderata o necessaria, ma penso che sia quella giusta. :(Scusa non ho potuto aiutare oltre.in buona fortuna :)

+0

L'effetto è ancora più pronunciato sui browser mobili in cui la memoria è un premio. Hai ragione che Raffaello ha bisogno di un refactoring per migliorare questo. –