javascript - style - title css

Controle y mida con precisión el tiempo que se muestra una imagen

Question

Para un estudio del tiempo de reacción ( consulte también esta pregunta si está interesado), queremos controlar y medir el tiempo de visualización de las imágenes. Nos gustaría dar cuenta del tiempo necesario para volver a pintar en las diferentes máquinas de los usuarios.

Editar : Originalmente, usé solo la ejecución en línea para el tiempo, y pensé que no podía confiar en que midiera con precisión cuánto tiempo la imagen era visible en la pantalla del usuario, porque la pintura lleva algo de tiempo.

Más tarde, encontré el evento " MozAfterPaint ". Necesita un cambio de configuración para ejecutarse en las computadoras de los usuarios y el correspondiente WebkitAfterPaint no lo hizo. Esto significa que no puedo usarlo en las computadoras de los usuarios, pero lo usé para mis propias pruebas. Pegué los fragmentos de código relevantes y los resultados de mis pruebas a continuación.
También verifiqué manualmente los resultados con SpeedTracer en Chrome.

// from the loop pre-rendering images for faster display
var imgdiv = $(''<div class="trial_images" id="trial_images_''+i+''" style="display:none"><img class="top" src="'' + toppath + ''"><br><img class="bottom" src="''+ botpath + ''"></div>'');
Session.imgs[i] = imgdiv.append(botimg);
$(''#trial'').append(Session.imgs);

// in Trial.showImages
$(window).one(''MozAfterPaint'', function () {
    Trial.FixationHidden = performance.now();
});
$(''#trial_images_''+Trial.current).show(); // this would cause reflows, but I''ve since changed it to use the visibility property and absolutely positioned images, to minimise reflows
Trial.ImagesShown = performance.now();

Session.waitForNextStep = setTimeout(Trial.showProbe, 500); // 500ms    

// in Trial.showProbe
$(window).one(''MozAfterPaint'', function () {
    Trial.ImagesHidden = performance.now();
});
$(''#trial_images_''+Trial.current).hide();
Trial.ProbeShown = performance.now();
// show Probe etc...

Los resultados de comparar las duraciones medidas usando MozAfterPaint y la ejecución en línea.

Esto no me hace muy feliz. En primer lugar, la duración media de la pantalla es aproximadamente 30 ms más corta de lo que me gustaría. En segundo lugar, la varianza usando MozAfterPaint es bastante grande (y más grande que para la ejecución en línea), así que no puedo simplemente ajustarla aumentando 30 minutos el setTimeout. En tercer lugar, esto es en mi computadora bastante rápida, los resultados para otras computadoras podrían ser peores.

Resultados de SpeedTracer

Estos fueron mejores El momento en que una imagen era visible generalmente estaba dentro de 4 (a veces) 10 ms de la duración prevista. También parecía que Chrome representaba el tiempo necesario para setTimeout a pintar en la llamada a setTimeout (de modo que había una diferencia de 504ms entre la llamada, si era necesario volver a pintar la imagen). Lamentablemente, no pude analizar y trazar los resultados de muchas pruebas en SpeedTracer, ya que solo se registra en la consola. No estoy seguro de si la discrepancia entre SpeedTracer y MozAfterPaint refleja diferencias en los dos navegadores o algo que falta en mi uso de MozAfterPaint (estoy bastante seguro de haber interpretado correctamente la salida de SpeedTracer).

Preguntas

Me gustaría saber

1. ¿Cómo puedo medir el tiempo que estuvo realmente visible en la máquina del usuario o al menos obtener números comparables para un conjunto de navegadores diferentes en diferentes computadoras de prueba (Chrome, Firefox, Safari)?
2. ¿Puedo compensar el tiempo de renderizado y pintura para llegar a 500 ms de visibilidad real? Si tengo que depender de una compensación universal, sería peor, pero aún mejor que mostrar las imágenes por una duración tan corta que los usuarios no las vean conscientemente en computadoras algo lentas.
3. Usamos setTimeout . Sé acerca de requestAnimationFrame pero no parece que podamos obtener ningún beneficio de su uso:
   Se supone que el estudio estará enfocado durante toda la duración del estudio y es más importante que tengamos una pantalla de +/- 500ms que una cierta cantidad de fps. Es mi entendimiento correcto?

Obviamente, Javascript no es ideal para esto, pero es lo menos malo para nuestros propósitos (el estudio tiene que ejecutarse en línea en las computadoras de los usuarios, pedirles que instalen algo podría asustar a algunos, Java no está incluido en los navegadores de Mac OS X nunca más).
Estamos permitiendo solo las versiones actuales de Safari, Chrome, Firefox y tal vez MSIE (detección de características para la API de performance.now y fullscreen, aún no he comprobado cómo funciona MSIE) en este momento.

Answer 1

¿Intentó obtener los milisegundos iniciales y después de que se disparó el evento, calcule la diferencia? en lugar de setTimeout. algo como:

var startDate = new Date();
var startMilliseconds = startDate.getTime();

// when the event is fired :
(...), function() {
    console.log(new Date().getTime() - startMilliseconds);
});

intente evitar el uso de jQuery si es posible. JS simple le dará mejores tiempos de respuesta y un mejor rendimiento general

Answer 2

Debido a que todavía no recibí más respuestas, pero aprendí mucho al editar esta pregunta, estoy publicando mi progreso hasta ahora como respuesta. Como verá, todavía no es óptimo y con gusto otorgaré la recompensa a cualquiera que lo mejore.

Estadística

• En el panel de la izquierda puede ver la distribución que me llevó a dudar de las estimaciones de tiempo que estaba obteniendo.
• El panel del medio muestra lo que logré después de los selectores de caché, reordenar algunas llamadas, usar un poco más de encadenamiento, minimizar los reflujos mediante el uso de la visibility y el posicionamiento absoluto en lugar de la display .
• El panel de la derecha muestra lo que obtuve después de usar una función adaptada de Joe Lambert utilizando requestAnimationFrame. Lo hice después de leer un blogpost sobre rAF que ahora también tiene una precisión de menos de milisegundos . Pensé que solo me ayudaría a suavizar las animaciones, pero aparentemente también ayuda a obtener mejores duraciones de visualización .

Resultados

En el panel final, la media del tiempo "pintura para pintar" es ~ 500ms, el promedio para la ejecución en línea dispersa de forma realista (tiene sentido, porque uso la misma marca de tiempo para terminar el ciclo interno más abajo) y se correlaciona con "pintura tiempo de "pintura".

Todavía hay un poco de variación en las duraciones y me encantaría reducirlo aún más, pero definitivamente es un progreso. Tendré que probarlo en algunas computadoras más lentas y algunas de Windows para ver si estoy realmente contento con eso, originalmente esperaba obtener todas las desviaciones por debajo de los 10 ms.

También podría recopilar más datos si crease un conjunto de pruebas que no requiera la interacción del usuario, pero quería hacerlo en nuestra aplicación real para obtener estimaciones realistas.

window.requestTimeout usando window.requestAnimationFrame

window.requestTimeout = function(fn, delay) {
    var start = performance.now(),
        handle = new Object();
    function loop(){
        var current = performance.now(),
            delta = current - start;

        delta >= delay ? fn.call() : handle.value = window.requestAnimationFrame(loop);
    };
    handle.value = window.requestAnimationFrame(loop);
    return handle;
};

Editar:

Una respuesta a otra pregunta mía se vincula a un buen artículo nuevo .