2013-02-26 14 views
11

To pytanie jest w duchu podobnym do tej drugiej kwestii, poprosił dwa lata temu: Why does Raphael's framerate slow down on this code?Raphael: Stopniowe ożywienie spowolnienie z nieskończonej prostej animacji

Używam Raphael 2.1.0 w Chromium 25 w następujący sposób:

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

Początkowo prostokąt obraca się płynnie, jak można się spodziewać. Po minucie lub dwóch rotacja trwa około 15 FPS. Po pięciu lub ośmiu minutach animacja trwa około 5 FPS.

Profile procesora Chrome wskazują, że w miarę, jak animacja staje się coraz bardziej nierówna, skrypt spędza coraz mniej czasu w postaci (program) i coraz więcej czasu w repush i eve.listeners.

Menedżer zadań Chrome nie wskazuje, że wystąpił wyciek pamięci w puli pamięci JS lub w Chrome, ale ujawnia, że ​​strona zużywa coraz więcej procesorów w czasie.

Po uruchomieniu tej strony w najnowszej wersji Firefoksa animacja staje się znacznie bardziej zmienna. Wyniki te zostały zweryfikowane w systemach Linux i Windows, więc nie jest to problem z systemem operacyjnym :).

Czy ktoś ma wgląd w to, co może być nie tak z moim kodowaniem lub wewnętrznymi Raphaela?

+2

Po uruchomieniu kodu w jsfiddle przez 10 minut za pomocą Chrome w wersji 25.0.1364.97 m, nie byłem w stanie zauważyć zmniejszenia liczby klatek na sekundę, w jaki sposób mierzysz liczbę klatek na sekundę? Czy możesz tego spróbować - http://jsfiddle.net/MEQRr/ – Neil

+0

Widziałem to działa na komputerze Kennetha, zmniejszenie liczby klatek na sekundę było dramatyczne, wcale nie subtelne. Po dziesięciu minutach wyglądało mniej więcej na 2 klatki na sekundę. –

+0

Po odejściu od twojego jsfiddle przez jakiś czas zdecydowanie doświadczyłem dużej degradacji framerate.Przetestowaliśmy to w Chrome na Macu, w systemach Windows, Linux i Firefox w systemie Linux. Jest obecny w każdej testowanej przeglądarce. Chrome 26.0.1410.12 programista. Podejrzewam, że degradacja będzie mniej wyraźna, jeśli zakładka jest kartą tła, a nie pierwszoplanową. –

Odpowiedz

2

Dobra, wiem, że to nie jest dokładnie odpowiedź, którą każdy chce usłyszeć (i jest dyskusyjnym wyrzutem), ale z wyglądu Rafaela i lektury powyższych komentarzy, nie mogę pomóc ale sądzę, że jest to kwestia zbierania śmieci i jest przyczyną różnic w wynikach we wszystkich przeglądarkach. Od szybkiego spojrzenia na źródło Rafaela, wygląda na to, że całkiem sporo varów jest zadeklarowanych lub zaimplementowanych w procesie animowania ramki, na podstawie klatki. Wiem na pewno, że przynajmniej w silniku V8 Chrome, każdy var jest zadeklarowany metodą śledzenia i umieszczany na stercie, opóźnienie w zmniejszeniu liczby klatek dalej wskazuje tylko, że garbage collector zaczyna kopać w tryb high, aby zwolnić fragmenty zadeklarowane vary, które nie są już używane. Założę się o dobre pieniądze, że gdybyś przesunął wiele deklaracji ze skryptu Rafaela na wyższy zakres (może nawet globalny, wzdycha!), Szczególnie podczas sekwencji animacji, znajdziesz znacznie poprawioną liczbę klatek na sekundę przebieg skryptu.

Wpadłem na ten problem przy niestandardowej implementacji adaptacji do webgl, zasadniczo robiłem polecenia webgl działa bez włączonego webgl. Rasterizator zbudowanego przeze mnie rurociągu miał podobny podobny problem, w zasadzie rysował ramy zaczynające się od 68 fps, ale pod koniec testu byłby obniżony do 13fps lub mniej, a przy 98% wykorzystania procesora. Dopóki nie oczyściłem każdej deklaracji, która stworzyła nowe przydziały pamięci poza zasięgiem potoku (i zrobiłem kilka dobrze zbadanych przyspieszających sztuczek związanych z wyszukiwaniem zmiennych), że w końcu byłem w stanie nadążyć i wyprodukować dobrze napisany rasteryzer, który może pompować około 3-5 MB/s pikseli na ekranie przy zachowaniu szybkości 50-60 fps.

Ponownie, nie jestem pewien, czy jest to odpowiedź, której potrzebujesz lub potrzebujesz, ale myślę, że jest poprawna. :(Przepraszamy, ale nie mogłem nic poradzić. Powodzenia :)

+0

Efekt jest jeszcze wyraźniejszy w przeglądarkach mobilnych, gdzie pamięć jest na wagę złota. Masz rację, że Rafael potrzebuje jakiegoś refaktoryzacji, żeby to poprawić. –