Javascript Speed ​​- Chrome v Firefox

Question

Escribí este pequeño juego al http://amarnus.me/games/dodge. Ahora, si intenta jugar el juego tanto en Firefox como en Chrome, notará claramente que es significativamente más lento en Firefox. Puedes llamarlo un código de trampa no intencional, sí. ;-)

Así que mi pregunta es: ¿esto se debe a un motor JavaScript más lento en Firefox en comparación con el de Chrome? ¿O tiene algo que ver con el malo coding? (En mi defensa, soy un Javascript newb)

Suponiendo que es el primero, entonces ¿no es esto un punto en contra (desventaja) de los juegos HTML5? (Los que usan la etiqueta <canvas> como la mía)

Answer 1

Firefox es más lento que Chrome en JavaScript. Sin embargo, creo que también es más lento con la etiqueta canvas. Esto probablemente mejorará con ff4 (¿has probado la versión beta?).

También hay un emulador de nidos en la web en algún lugar con js y lienzo, y se ejecuta en aproximadamente 30 fps en cromo (si mal no recuerdo), pero solo alrededor de 10 en ff.

El tiempo es probablemente tu mejor amigo :-P, aunque siempre puedes intentar optimizarlo.

Creo que los juegos de navegador llegarán a tiempo, pero aún no está listo para nada demasiado avanzado. Tal vez sobre el tiempo sale ie12 :-P.

[Editar] Btw: He probado el juego en FF4b1, y pensé que funcionaba genial. Probablemente no tan rápido como en cromo, pero no muy lejos :).

Answer 2

jQuery animate hace algo similar a su movimiento de objeto DOM.

Me gustaría ver su código y ver cómo hacen el movimiento real, es probablemente la forma más eficiente ya que está construido en jQuery.

Answer 3

Chrome es designed para tener un motor de JavaScript más rápido.

No creo que diga nada sobre los juegos de HTML5. Siempre encontrará usuarios con configuraciones más rápidas o más lentas que otros, ya sea hardware, software o el hábito personal de un usuario de mantener muchas aplicaciones ejecutándose a la vez. Si su juego fue escrito en Flash o Java, entonces un usuario con hardware más lento vería una desaceleración similar.

Es posible que pueda hacer cambios en su código para acelerarlo. No lo he examinado con gran detalle, pero veo que tienes construcciones como if(dodge.goRight == true .... Aunque no es una fuente de lentitud, esto sugiere que es posible que no haya utilizado la solución óptima en todas partes.

Answer 4

Puede probar el motor de su navegador JavaScript con el sitio de IE.

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

Ellos afirman que la velocidad más alta del motor JavaScript que tienen con IE9

Answer 5

Me culpo a una gran parte de ella en setTimeout y setInterval tener un mínimo de 10 ms ~ en los navegadores tales como Internet Explorer y Firefox . Esto fue adoptado originalmente para evitar que las páginas consumieran toda la CPU si ingenuamente usaban 0ms para funcionar lo más rápido posible. Chrome se lanzó sin límite pero ahora es moving to a 4ms minimum para que coincida con la recomendación en HTML5.

John Resig hassomeawesomeposts investigar límites SetTimeOut y precisión.

¡Los navegadores de Mozilla en realidad le pueden decir qué tan tarde (o temprano!) Se están ejecutando con cada llamada setInterval. Consulte el artículo de MDC setTimeout (google "mdc settimeout" y revise la nota gris en la sección de sintaxis).

Además de los problemas con el temporizador, Firefox es generalmente más lento en la ejecución de JS (al menos por ahora) y se siente como si Skia (la lib de gráficos de Chrome) fuera más rápido en rasterizar también.

Espero que esto ayude :)

(que originalmente tenía un montón de enlaces útiles aquí, pero es mi primer post y el filtro de correo no deseado me dio una bofetada hacia abajo.)

Answer 6

Con el fin de obtener ayuda es posible considerar proporcionando una versión no minificada de su script.

Veo que hay 8ms setIntervals en su código. Como se mencionó anteriormente, Firefox nunca baja de los 10 ms (todavía). Sin embargo, jugar tu juego en FFox 4 es muy divertido. Vi dos muestras muy pequeñas que claramente fueron causadas por la recolección de basura. Chrome tiene una ventaja sobre Fox en ese sentido. A pesar de que SpiderMonkey (que maneja GC en Firefox) ha mejorado dramáticamente de 3.5 a 3.6, todavía no es lo suficientemente bueno para muchos juegos. En 4.0 es mucho mejor, pero aún no es tan bueno como en Chrome u Opera. (Se está trabajando en ello.)

Jugando el juego y mirando brevemente su código, no veo complejidad que pueda causar que Firefox no sea capaz de manejar lo que está sucediendo. También Firefox 4 tiene Canvas acelerado por hardware que es marginalmente más rápido que IE9 y mucho más rápido que Chrome.

Hay una noción en la web de que Chrome es más rápido que Gecko en lo que respecta al lienzo, pero eso se debe a que las personas rara vez perfilan sus páginas. De hecho, el lienzo en Firefox 3.6 ya es al menos tan rápido como en Chrome, pero muchas pruebas no lo muestran ya que JavaScript es más lento. (Y algunas pruebas de JavaScript son más lentas porque Firefox no maneja bien el arnés de prueba).

Todo esto genera mucha confusión y desinformación. La conclusión es que su juego debería estar bien en Firefox 4. Debería ver si hay algo que pueda hacer para evitar la activación innecesaria de GC. P.ej. ¿Estás reutilizando variables o creando nuevas innecesarias?

Sin embargo, en Opera 10.53 no fue agradable. No porque Opera no pudiera seguir el ritmo de la velocidad, sino porque en lugar de mover la pieza de abajo, se mantuvo inmóvil y todo el campo de juego se movió en su lugar. (Logré pasar al nivel 17 en mi primer intento a pesar de esto). En Opera 10.6 la página no se carga correctamente.

Probablemente necesite depurar su código, o quizás presentar un error con Opera si se trata de una regresión. (Voy a TITLE_TWEETTHIS para llamar su atención.)

Answer 7

probar esta técnica: setTimeout with a shorter delay

Avísame si ayuda. Soy un poco curioso ahora. :)

¡Buena suerte!