Javascript Speed ​​- Chrome v Firefox

Question

Napisałem tę małą grę pod numerem http://amarnus.me/games/dodge. Teraz, jeśli spróbujesz grać w grę zarówno w Firefoksie, jak i w Chrome, zauważysz wyraźnie, że jest znacznie wolniejszy w Firefoksie. Możesz nazwać to niezamierzonym kodem, tak. ;-)

Moje pytanie brzmi - czy jest to spowodowane wolniejszym silnikiem JavaScript w przeglądarce Firefox w porównaniu z Chrome? A może ma coś wspólnego ze złym coding? (W mojej obronie jestem nowicjuszem Javascript)

Zakładając, że jest to pierwszy, czy to nie jest punkt przeciwko (wadzie) gier HTML5? (Te, które używają znacznika <canvas>, takiego jak mój)

Answer 1

Firefox jest wolniejszy od chrome w javascript. Uważam jednak, że wolniej jest też używać tagu canvas. Prawdopodobnie poprawi się to z FF4 (czy wypróbowałeś wersję beta?).

Istnieje również emulator nes w sieci gdzieś za pomocą js i canvas, i działa w około 30 fps na chrome (jeśli pamiętam o poprawnie), ale tylko około 10 w ff.

Czas jest prawdopodobnie Twoim najlepszym przyjacielem :-P, ale możesz spróbować zoptymalizować.

Wierzę, że gry przeglądarkowe pojawią się na czas, ale nie są jeszcze gotowe do niczego zbyt zaawansowanego. Może o czasie, tj. 12 wyjdzie :-P.

[Edytuj] Btw: Próbowałem gry w FF4b1, i pomyślałem, że działa świetnie. Prawdopodobnie nie tak szybko jak w chromie, ale niedaleko od niego :).

Answer 2

jQuery animate robi coś podobnego do ruchu obiektu DOM.

Chciałbym zajrzeć do ich kodu i zobaczyć, jak robią rzeczywisty ruch, to prawdopodobnie najbardziej skuteczny sposób, ponieważ jest on wbudowany w jQuery.

Answer 3

Chrome to designed, aby mieć szybszy silnik JavaScript.

Nie sądzę, że mówi coś o grach HTML5. Zawsze znajdziesz użytkowników z szybszymi lub wolniejszymi ustawieniami niż inni, czy to sprzętem, oprogramowaniem, czy też zwyczajami użytkownika utrzymywania wielu aplikacji jednocześnie. Jeśli twoja gra była napisana w technologii Flash lub Java, wówczas użytkownik z wolniejszym sprzętem zobaczyłby podobne spowolnienie.

Możliwe jest wprowadzenie zmian w kodzie w celu przyspieszenia. Nie zbadałem tego szczegółowo, ale widzę, że masz konstrukcje takie jak if(dodge.goRight == true .... Chociaż nie jest to powolne źródło, wskazuje to na to, że nie zawsze korzystałeś z optymalnego rozwiązania.

Answer 4

Możesz przetestować silnik JavaScript przeglądarki z witryną IE.

http://ie.microsoft.com/testdrive/

one dochodzić do najwyższej prędkości silnika javascript mają z IE9

Answer 5

bym winien dużą część z nich na setTimeout i setInterval posiadające minimum ~ 10ms w przeglądarkach takich jak IE i Firefox . Zostało to pierwotnie przyjęte, aby powstrzymać strony przed zużyciem całego procesora, gdyby naiwnie używał 0ms, aby działał tak szybko, jak to możliwe. Chrome został uruchomiony bez limitu, ale teraz jest moving to a 4ms minimum, aby pasował do rekomendacji w HTML5.

John Resig hassomeawesomeposts badanie limitów i dokładności setTimeout.

Przeglądarki Mozilli mogą powiedzieć, jak późno (lub wcześnie!) Działają z każdym wywołaniem setInterval. Sprawdź artykuł setTimeout MDC (google "mdc settimeout" i sprawdź szarą notatkę w sekcji składni).

Oprócz problemów z timerem, Firefox jest generalnie wolniejszy w wykonaniu JS (przynajmniej na razie) i wydaje się, że Skia (grafika Chrome) jest szybsza również przy rasteryzacji.

Nadzieja to pomaga :)

(I pierwotnie miał kilka przydatnych linków, ale to jest mój pierwszy post i filtr spamu klepnął mnie w dół.)

Answer 6

W celu uzyskania pomocy można rozważyć zapewniając niezmineralizowaną wersję twojego skryptu.

Widzę, że w kodzie znajduje się 8ms setIntervals. Jak wspomniano powyżej, Firefox nigdy nie przechodzi poniżej 10 ms (jeszcze). Jednak gra w FFox 4 jest bardzo przyjemna. Widziałem dwie bardzo małe hikki, które najwyraźniej zostały spowodowane przez odśmiecanie. Chrome ma przewagę nad Foxem pod tym względem. Mimo że SpiderMonkey (obsługujący GC w Firefoksie) poprawił się dramatycznie z 3,5 do 3.6, to nadal nie jest wystarczająco dobry dla wielu gier. W wersji 4.0 jest o wiele lepszy, ale wciąż nie tak dobry jak w Chrome czy Opera. (Trwają prace nad nim).

Grając w grę i patrząc krótko na twój kod, nie widzę żadnej złożoności, która powodowałaby, że Firefox nie byłby w stanie poradzić sobie z tym, co się dzieje. Również Firefox 4 ma sprzętowo przyspieszone Canvas, które jest marginalnie szybsze niż IE9 i dużo szybsze niż Chrome.

Istnieje w Internecie pogląd, że Chrome jest szybszy niż Gecko, jeśli chodzi o płótno, ale dzieje się tak, ponieważ ludzie rzadko profilują swoje strony. W rzeczywistości płótno w Firefoksie 3.6 jest już co najmniej tak samo szybkie jak w Chrome, ale wiele testów nie pokazuje tego, ponieważ JavaScript jest wolniejszy. (Niektóre testy JavaScript są wolniejsze, ponieważ Firefox nie radzi sobie dobrze z szelkami testowymi.)

Wszystko to prowadzi do wielu nieporozumień i dezinformacji. Najważniejsze jest to, że twoja gra powinna być dobra w Firefoksie 4. Powinieneś zobaczyć, czy jest coś, co możesz zrobić, aby uniknąć wyzwalania niepotrzebnego GC. Na przykład. czy ponownie używasz zmiennych lub tworzysz zbędne nowe?

Jednak w Operze 10.53 nie było to przyjemne. Nie dlatego, że Opera nie nadążała za prędkością, ale zamiast przesuwać dolną część, była nieruchoma, a zamiast niej przesunięto całe boisko. (Mimo to udało mi się przejść na poziom 17 w mojej pierwszej próbie.) W Operze 10.6 strona nie ładuje się poprawnie.

Prawdopodobnie potrzebujesz debugowania kodu - lub może zgłosić błąd do Opery, jeśli jest to regresja. (Będę ćwierkać to aby przyciągnąć ich uwagę.)

Answer 7

wypróbować tę technikę: setTimeout with a shorter delay

Daj mi znać, jeśli to pomaga. Jestem teraz ciekawy. :)

Powodzenia!