Cómo funciona la puntuación de ScreenTest.Pro

Esta es la página de metodología. No hemos simplificado nada con fines comerciales; si el código y esta página discrepan alguna vez, es un error y queremos saberlo. (Versión del benchmark al escribir estas líneas: 2.2.0.)

La pregunta que plantea el benchmark

La mayoría de benchmarks gráficos fijan la carga de trabajo y miden la tasa de fotogramas. El nuestro lo invierte: fija un tiempo de fotograma objetivo y busca la carga de trabajo más exigente que tu dispositivo puede mantener dentro de ese tiempo. El resultado es la «carga estable máxima» de cada escena —por ejemplo, 840.000 partículas de nebulosa—, y con ella se calcula la puntuación.

¿Por qué invertirlo? Porque las tasas de fotogramas se saturan. En un equipo rápido, una carga fija alcanza la frecuencia de actualización de la pantalla y deja de aportar información; la pregunta interesante es cuánto más habría soportado. Buscar el límite mantiene la medición útil desde un teléfono de hace cinco años hasta una GPU de escritorio, usando las mismas escenas.

Qué se ejecuta

El perfil Estándar incluye cinco escenas destacadas y una de control, cada una centrada en un aspecto distinto:

El renderizado usa una relación de píxeles limitada a 1,5× y un tope de tamaño interno, de modo que un monitor 5K y un portátil 1080p afrontan cantidades de píxeles comparables. El azar usa una semilla y los pasos de simulación son fijos: cada ejecución de una versión realiza exactamente el mismo trabajo.

Cómo se determina la estabilidad

El motor nunca lee un contador de FPS. Recoge tiempos de fotograma del reloj de animación del navegador en ventanas de aproximadamente 0,7–1,6 segundos y exige dos condiciones a cada ventana:

• como mucho un 5% de los fotogramas puede incumplir el umbral de aprobación: 17,5 ms en pantallas de sincronización adaptativa; en pantallas de frecuencia fija, el primer intervalo de vsync en el que un trabajo dentro de presupuesto ya no podría encajar (25,0 ms a 60 Hz, 20,8 ms a 120 Hz);
• la media recortada —descartando el 2% peor de los fotogramas— debe mantenerse dentro de 16,67 ms × 1,15.

Contar los incumplimientos en vez de promediarlos permite que una pausa del recolector de basura sea un fotograma malo y no una ventana fallida; la media recortada es la red de seguridad que impide que unos pocos fallos enormes pasen solo por ser pocos.

Por qué el umbral tiene en cuenta tu pantalla: un monitor fijo de 60 Hz puede presentar un fotograma a los 16,7 ms o a los 33,3 ms y nada intermedio, mientras que un panel de portátil con sincronización adaptativa devuelve un fotograma de 18 ms como un fotograma de 18 ms. Con las tolerancias de media y P95 de la versión 2.1.0, esa diferencia dejaba que los paneles adaptativos navegaran a 55 fps y aprobaran, mientras que los monitores de 60 Hz tenían que sostener 60 de verdad: la misma GPU puntuaba menos en un escritorio que dentro de la tapa de un portátil. Por eso, antes de la primera escena, una sonda de cadencia de unos 600 ms observa cómo devuelve fotogramas tu pantalla, y el criterio se ajusta para que «sostiene 60 fps» signifique lo mismo en cualquier clase de pantalla. Si la sonda detecta que la pantalla está limitada por debajo de unos 50 Hz —modo de bajo consumo, un cable a 30 Hz—, la prueba se niega a empezar en lugar de juzgar una GPU a través de una rendija de 30 Hz.

El presupuesto de 16,67 ms en sí nunca cambia con la frecuencia de actualización. Una pantalla de 120 Hz entrega fotogramas con una cadencia de 8,3 ms cuando la carga es ligera, pero para aprobar basta con permanecer dentro del presupuesto de 60 por segundo: el hardware de alta frecuencia se mide en igualdad de condiciones y no se penaliza por mostrar fotogramas adicionales.

La búsqueda

Cada escena recorre una máquina de estados: preflight → baseline → warmup → ramp → bracket → confirm → anchor.

1. Baseline mide una carga ligera conocida, que servirá como referencia térmica.
2. Ramp multiplica la carga aproximadamente por 1,5 tras cada ventana superada, hasta que una falla.
3. Bracket aplica una búsqueda binaria entre el último valor superado y el primero fallido, hasta reducir el intervalo a cerca del 6%.
4. Confirm exige tres ventanas consecutivas superadas con la carga candidata, dentro de un presupuesto de cuatro. Una ventana mala al principio aún puede recuperarse; dos fallos seguidos, o agotar el presupuesto sin lograr tres aciertos consecutivos, descartan el nivel y reducen la carga candidata.
5. Anchor vuelve a ejecutar la carga de referencia. Si ahora tarda más de un 15% respecto al inicio, el dispositivo cambió durante la medición —casi siempre por limitación térmica— y la escena queda marcada como desviación en lugar de fingir que no ocurrió nada. También se registra la magnitud de la ralentización, no solo el hecho de que se produjo.

Unos pocos fotogramas posteriores a cada cambio de carga se descartan antes de reanudar la estadística: cambiar la carga vuelve a reservar búferes y búferes de render de la GPU, y el navegador carga ese coste a un único fotograma largo. Ese tropiezo pertenece a la transición, no a la carga de trabajo; la versión 2.1.0 lo contaba, y en la escena que redimensiona su búfer de render en cada peldaño detenía la búsqueda muy por debajo de lo que el hardware sostiene en realidad.

Cada fase tiene un límite estricto de tiempo: 30 segundos por escena y 200 segundos por prueba. Pasar la pestaña a segundo plano pausa la medición e invalida la ventana actual; cambiar el tamaño reconstruye la escena y repite el calentamiento. Ningún recorrido de la máquina de estados puede quedarse bloqueado.

De las cargas a una puntuación

La puntuación es una función pura de los resultados registrados; podrías recalcularla a mano:

1. La carga estable máxima de cada escena se divide por la carga de referencia de esa escena, una constante de calibración fija para cada versión. Como orientación, un equipo de escritorio sólido de 2025 queda cerca de 1,0.
2. Las proporciones tienen un suelo de 0,05 y un techo en el límite de la escalera de cada escena: la carga más pesada que esa escena puede montar físicamente, situada aproximadamente 10× por encima del hardware más rápido que hemos medido. Así, la puntuación solo deja de subir donde termina la propia medición. (La versión 2.1.0 recortaba todas las escenas en un 20× plano; un M4 Max clavaba dos escenas contra ese límite y una tercera contra el techo de medición, y por eso buques insignia de Apple sin relación entre sí acababan dando totales casi idénticos.)
3. Las proporciones limitadas se combinan mediante una media geométrica ponderada. Las cinco escenas destacadas aportan la mayor parte del peso y el control de Canvas 2D, un 10%. Se usa la media geométrica porque premia el equilibrio: un equipo bueno en todo supera a otro excepcional en una tarea y pésimo en las demás.
4. El resultado se multiplica por 1.000, se aplica la deducción por estabilidad —un 3% por escena marcada, ya sea por desviación o por un nivel sin confirmar, con un máximo total del 10%— y se redondea.

Los niveles usan umbrales fijos para cada versión. Como una puntuación de 1.000 equivale a la máquina de referencia, cada nivel es en realidad un múltiplo de ella: Básico por debajo de 1.000, Equilibrado hasta 2.999, Rápido hasta 8.999 y Extremo a partir de ahí; es decir, menos de 1×, hasta 3×, hasta 9× y más. Sirven para dar un nombre manejable a la cifra; las puntuaciones por escena son la información verdaderamente útil.

Qué invalida una comparación

• Nunca se comparan versiones diferentes del benchmark. Cambiar un solo shader altera la carga; la versión indicada en la hoja de resultados forma parte de la puntuación.
• Las pruebas de compatibilidad —sin WebGL2— usan solo escenas clásicas y se puntúan en su propio espacio, claramente identificado.
• Las pruebas limitadas por calor —todas las escenas medidas y confirmadas, pero el dispositivo se calentó y perdió velocidad— son mediciones reales de rendimiento sostenido, así que puntúan con normalidad y entran en la tabla de mejores puntuaciones con la marca visible en su fila. La mayoría de las pruebas en teléfonos acaban aquí: eso es física, no un defecto.
• Las pruebas degradadas —una escena que no produjo nada aprovechable, o un nivel que la búsqueda nunca pudo confirmar— son un mínimo y no un máximo, así que se quedan fuera de la tabla. Se conservan igualmente, siguen contando en las medianas agregadas, y la hoja de resultados indica qué escena falló y por qué.
• Ambas marcas viajan con la prueba a nuestro conjunto de datos anónimo, de modo que cualquier cifra publicada puede separarlas.

Variación entre pruebas y qué esperar

En un equipo conectado a la corriente y sin otras tareas, las ejecuciones consecutivas suelen quedar a pocos puntos porcentuales unas de otras; la exigencia de ventanas consecutivas durante la confirmación es lo que aporta esa estabilidad. Con batería, en modo de ahorro o con el chasis caliente, cabe esperar más dispersión y probablemente una marca de limitación por calor. No es que el benchmark tenga un mal día: el dispositivo ofrece realmente menos rendimiento. Enfriarlo y enchufarlo antes de la prueba es lo más eficaz que puedes hacer para obtener una cifra representativa. El artículo sobre los límites de un benchmark en el navegador explica cómo interpretar la cifra una vez obtenida.