En todas partes veo el consejo de usar requestAnimationFrame. Lo que nadie te dice es que Chrome acelerará a 48 o 30 fps según tu plan de energía, cuántas pestañas tengas abiertas y la fase de la luna, sin notificarte de ninguna manera. Hará esto independientemente de la carga de trabajo real que esté haciendo.
Para una animación real, esto está bien, aunque no sea óptimo. Utiliza el tiempo transcurrido para generar un nuevo cuadro de animación independiente de la velocidad de cuadro.
Pero para algo como un emulador es inaceptable.
Estoy usando SharedArrayBuffers, por lo que ya tengo los encabezados molestos incluidos con mi JavaScript que te permite usar algunas API adicionales. ¿Hay alguna alternativa a requestAnimationFrame o alguna forma de obligarlo a ir al menos a 60 Hz?
No, no hay alternativa, ya que el trabajo de pintura del navegador se ejecuta tantas veces como se llama a la devolución de llamada de requestAnimationFrame (cuando sigue programándola en cada próxima llamada). Entonces, si hiciera iteraciones más frecuentes de alguna manera, no ayudaría, ya que algunos de estos cambios no llegarían a la pantalla.
Si el problema tiene que ver con el tiempo , tenga en cuenta que la devolución de llamada se realiza con una marca de tiempo, lo que puede ayudarlo a realizar cálculos realistas. Esto no cambia la velocidad de fotogramas variable, pero al menos le permite saber cuánto tiempo ha pasado y basar sus cálculos en eso y no en la cantidad de veces que se llama a la devolución de llamada.