Estoy buscando información sobre cómo interpretar Chrome Dev Tools cuando muestra un marco caído. Los documentos oficiales no parecen cubrir este o el curso de Udacity sobre la solicitud de fotogramas de animación.
Tengo un proyecto webGL (usando Three.js) y veo lo siguiente en las herramientas de desarrollo de Chrome cuando estoy animando: estoy usando requestAnimationFrame.
Para ser claros, NO ESTOY preguntando cómo arreglar mi código o qué está mal con mi código. Estoy pidiendo ayuda para entender lo que esto me dice, el código es irrelevante.
Si alguien pudiera sugerir...
En la captura de pantalla anterior, puede ver que tarda 15,7 ms, pero advierte que hay un cuadro caído. Si hago clic en la tarea, parece que toma 12 ms, entonces, ¿de dónde provienen los 3,7 ms adicionales? ¿Cómo puedo averiguarlo, ya que todas mis funciones están cubiertas en la parte de "tarea"?
¿El verde de 1,0 ms que se ve antes de la referencia de 15,7 ms es un cuadro? - ¿Significa eso que estoy activando un requestAnimationFrame pero sin hacer nada? Dado que no se muestra nada en las herramientas de desarrollo, ¿cómo puedo averiguar qué lo está activando?
EDITAR. Aquí hay un ejemplo más extremo que puedo obtener, como puede ver, es el mismo tipo de cosa, mi tarea en realidad tomó 9 ms, ¡pero dice que el cuadro fue de 82 ms!
Esta es solo mi interpretación personal.
marco caído
Un "cuadro caído" puede ocurrir incluso con una animación muy simple, pero al contrario de lo que escribí en mi comentario anterior, no corresponde a un cuadro que realmente se representa en la pantalla.
Si crea una animación web muy simple como opacity: [0, 1]
, creada a través de CSS o JS, y registra sus actuaciones a través del panel correspondiente en Chrome v90, debería ver que el 98% de los cuadros son verdes y el 2% son rojo (fotogramas perdidos). Tenga en cuenta que los marcos verdes y rojos pueden durar más ya veces menos de 16,67 ms.
También tenga en cuenta que creo que se informaron incluso más cuadros rojos en Chrome v89 para este tipo de animación.
Los 3,7 ms después de la tarea de animación
Este tiempo parece ser utilizado por la Unidad de proceso gráfico para hacer que la composición funcione, como lo indica la tarea de GPU (verde, ~1 ms) justo después de la tarea de animación. Sin embargo, todavía quedan 2,7 ms sin ninguna explicación.
Chrome DevTools parece no ser 100% confiable. Puede ser la latencia entre la GPU y la CPU, o falta información. Si graba una animación simple durante menos de ~6 s, a veces no se registra ninguna información. Pero creo que medir el rendimiento de la animación siempre ha sido difícil y que Chrome está tratando de mejorarlo en sus últimas versiones.
El 1 ms antes de la animación.
Creo que este es el tiempo que tarda el navegador en ejecutar las tareas obligatorias antes de comenzar un nuevo ciclo de renderizado.
En resumen, los términos "fotograma" y "fps" (fotograma por segundo) parecen usarse de una manera que es bastante confusa de entender.
No soy de Google, ni siquiera un experto en DevTools, solo paso después de leer unas líneas de código en Chrome DevTools.
Hay algunas razones por las que se cae un marco, puede verificar en FrameDropReason .
Pero para comprender cuál es el motivo de la pérdida de fotogramas, no encuentro otra forma mejor que leer el JSON de creación de perfiles, que puede encontrar algo como esto:
{"args":{"data":{"compositeFailed":8192,"unsupportedProperties":["background-color"]}},"cat":"blink.animations,devtools.timeline,benchmark,rail","id2":{"local":"0x3b08a0fb80"},"name":"Animation","ph":"n","pid":23024,"scope":"blink.animations,devtools.timeline,benchmark,rail","tid":259,"ts":71014192568},
Básicamente dice que el marco cayó por el compositor, debido a problemas de CSS no compatibles. Más detalles sobre las razones de falla del Compositor aquí .
También es bueno analizar este problema que rastrea la adición de Dropped Frame
.
Nuevamente, no estoy del todo seguro, solo algunos consejos para que los investigues.