Como funciona a pontuação do ScreenTest.Pro

Esta é a página de metodologia. Nada aqui foi simplificado para fins de marketing; se o código e esta página algum dia discordarem, isso é um bug e queremos saber. (Versão do benchmark no momento em que isto foi escrito: 2.5.0.)

A pergunta que o benchmark faz

A maioria dos benchmarks gráficos fixa a carga de trabalho e mede a taxa de quadros. O nosso faz o inverso: fixa a meta de tempo de quadro e procura a carga mais pesada que seu dispositivo consegue sustentar dentro dela. O resultado é a “carga estável máxima” de cada cena — por exemplo, 840.000 partículas de nebulosa — e é daí que vem a pontuação.

Por que inverter? Porque as taxas de quadros saturam. Em uma máquina rápida, uma carga fixa encosta na taxa de atualização da tela e deixa de revelar qualquer coisa; a pergunta interessante é quanto mais ela poderia suportar. Procurar o limite mantém a medição relevante desde um celular de cinco anos atrás até uma GPU de desktop, sempre com as mesmas cenas.

O que é executado

O perfil Padrão inclui cinco cenas de destaque e uma cena de controle, cada uma pressionando um aspecto diferente:

A renderização usa uma proporção de pixels limitada a 1,5× e um teto para o tamanho interno, por isso um monitor 5K e um notebook 1080p enfrentam quantidades de pixels comparáveis. A aleatoriedade usa uma semente e os passos da simulação são fixos: toda execução de uma mesma versão realiza exatamente o mesmo trabalho.

Como a estabilidade é avaliada

O motor nunca lê um contador de fps. Ele coleta tempos de quadro do relógio de animação do navegador em janelas de aproximadamente 0,7–1,6 segundo e exige duas coisas de cada janela:

• no máximo 5% dos quadros podem passar do limiar de aprovação — 17,5 ms em telas com sincronização adaptativa; em telas de taxa fixa, o primeiro intervalo de vsync em que um trabalho dentro do orçamento nunca conseguiria cair (25,0 ms a 60 Hz, 20,8 ms a 120 Hz);
• a média aparada — descartados os 2% piores quadros — precisa ficar dentro de 17,5 ms, o mesmo orçamento sustentado em toda classe de tela.

Contar as falhas em vez de tirar a média delas transforma uma pausa do coletor de lixo em um quadro ruim, e não em uma janela reprovada; a média aparada é o limite do desempenho sustentado e, desde a 2.3.0, é um único número em todo lugar — os timestamps reais de vsync se mostraram mais bagunçados do que o modelo de taxa fixa que a 2.2.0 supunha, e a antiga tolerância da média aparada, mais frouxa, dava sem alarde às telas de taxa fixa um orçamento ~9% mais fácil que às adaptativas.

Por que o limiar de falhas ainda se importa com a sua tela: um monitor fixo de 60 Hz pode apresentar um quadro depois de 16,7 ms ou de 33,3 ms e nada no meio, enquanto uma tela de notebook com sincronização adaptativa devolve um quadro de 18 ms como 18 ms mesmo. Por isso, antes da primeira cena, uma sondagem de cadência de cerca de 600 ms observa como sua tela devolve quadros, e o limiar de quadros perdidos se ajusta para que “sustenta 60 fps” seja a mesma afirmação em qualquer classe de tela. A mesma sondagem passa então cerca de 2 s verificando se a própria máquina já engasga sem carga — uma máquina ocupada recebe um aviso antes da execução de três minutos, não um piso surpresa depois dela. Se a sondagem encontra uma tela travada abaixo de ~50 Hz — modo de baixo consumo, um cabo de 30 Hz — a execução se recusa a começar em vez de avaliar uma GPU por um canudo de 30 Hz.

O orçamento de 16,67 ms em si nunca muda com a taxa de atualização. Uma tela de 120 Hz entrega quadros numa cadência de 8,3 ms quando as coisas estão fáceis, mas passar exige apenas ficar dentro do orçamento de 60 por segundo — hardware de alta taxa é medido em pé de igualdade, não punido por mostrar seus quadros extras.

A busca

Cada cena percorre uma máquina de estados: preflight → baseline → warmup → ramp → bracket → confirm → anchor.

1. Baseline mede uma carga leve conhecida — ela vira a referência térmica.
2. Ramp multiplica a carga por cerca de 1,5× a cada janela aprovada até uma janela falhar.
3. Bracket faz busca binária entre a última carga aprovada e a primeira reprovada até a faixa estreitar para uns 6%.
4. Confirm exige três janelas aprovadas consecutivas na carga candidata, dentro de um orçamento de quatro. Uma janela ruim logo no começo ainda dá para recuperar; duas falhas seguidas, ou gastar o orçamento sem três em sequência, rejeitam o nível e o candidato desce um degrau.
5. Anchor roda de novo a carga de base. Se agora ela roda mais de 15% mais devagar do que no começo, o aparelho mudou embaixo de nós — quase sempre limitação térmica — e a cena é marcada como desvio em vez de fingir que nada aconteceu. O tamanho da desaceleração também fica registrado, não só o fato dela.

Alguns quadros logo depois de cada mudança de carga são descartados antes de a estatística recomeçar: mudar a carga realoca buffers de GPU e alvos de renderização, e o navegador cobra isso como um único quadro longo. Esse soluço pertence à transição, não à carga de trabalho — a 2.1.0 o contava, e na cena que redimensiona seu alvo de renderização a cada degrau ele parava a busca muito abaixo do que o hardware de fato sustenta.

Cada fase tem um limite de tempo rígido (30 s por cena, 200 s por execução, estendido brevemente só quando novas tentativas de fato entram na fila). O aquecimento antes da medição também se adapta: numa primeira visita os shaders são compilados, e a etapa preliminar espera — até 4 s — enquanto os tempos de quadro ainda mostram esses engasgos de compilação, para que a escada comece numa máquina aquecida em vez de se afogar neles. Mandar a aba para segundo plano pausa a medição e invalida a janela atual; redimensionar reconstrói a cena e reaquece. E uma cena que não mediu nada, numa execução cujas cenas seguintes se recuperaram, ganha exatamente mais uma medição no fim — desde que uma nova checagem de sossego diga que a máquina se acalmou. Nada é fabricado; a cena simplesmente roda de novo, e o resultado da nova tentativa substitui o vazio. Não existe caminho pela máquina de estados que trave.

Das cargas à pontuação

A pontuação é uma função pura dos resultados registrados — você poderia recalculá-la à mão:

1. A carga estável máxima de cada cena é dividida pela carga de referência daquela cena (uma constante de calibração congelada por versão; grosso modo, um desktop sólido de 2025 fica perto de 1,0).
2. As razões têm piso em 0,05 e são limitadas ao teto de escada da própria cena — a carga mais pesada que aquela cena consegue montar fisicamente, colocada mais ou menos 10× além do hardware mais rápido que já medimos — para que a pontuação só possa parar de subir onde a própria medição termina. (A 2.1.0 travava toda cena num 20× plano; um M4 Max encostava duas cenas nesse teto e uma terceira no teto de medição, e é por isso que topos de linha da Apple sem parentesco continuavam relatando totais quase idênticos.)
3. As razões limitadas se combinam numa média geométrica ponderada — as cinco cenas Signature carregam a maior parte do peso, o controle Canvas 2D fica com 10%. Geométrica porque premia equilíbrio: uma máquina boa em tudo ganha de uma máquina lendária numa coisa e péssima em outra.
4. Multiplique por 1000, aplique o desconto de estabilidade — 3% por cena marcada, seja a marca desvio ou um nível não confirmado, no máximo 10% no total — e arredonde.

As faixas são limiares fixos por versão e, como uma pontuação é 1000× a máquina de referência, cada faixa é na prática um múltiplo dela: Básico abaixo de 1000, Equilibrado até 2999, Rápido até 8999, Extremo acima disso — ou seja, abaixo de 1×, até 3×, até 9×, e depois além. Elas existem para dar uma alça ao número; as pontuações por cena é que são a informação de verdade.

O que invalida comparações

• Versões diferentes do benchmark nunca se comparam. Mudar um único shader muda a carga de trabalho; a string de versão na sua folha de resultados faz parte da pontuação.
• Execuções de compatibilidade (sem WebGL2) usam apenas cenas Clássicas e pontuam no espaço delas, com rótulo claro.
• Execuções limitadas por calor — todas as cenas medidas, mas o aparelho esquentou e desacelerou, ou sustentou um nível que passava mas não pôde ser confirmado por três janelas seguidas — são medições reais de desempenho sustentado, então pontuam normalmente e entram no ranking com a marca visível na linha. A maior parte das execuções em celular cai aqui; isso é física, não defeito.
• Execuções degradadas — uma cena que não produziu nada aproveitável — são um piso e não um pico, então ficam fora do ranking e das medianas publicadas. Elas continuam guardadas, e a folha de resultados diz qual cena e por quê.
• As duas marcas viajam com a execução para o nosso conjunto de dados anônimo, então qualquer número publicado consegue separá-las.

Variação entre testes e o que esperar

Numa máquina na tomada e ociosa, execuções consecutivas costumam ficar dentro de poucos por cento — quem compra isso é a exigência de janelas consecutivas na fase de confirmação. Na bateria, em modo de economia ou com o chassi quente, espere mais dispersão e provavelmente uma marca de limitação térmica; não é o benchmark de mau humor, é o seu aparelho oferecendo menos de verdade. Deixar esfriar e ligar na tomada antes de uma execução é a coisa mais eficaz que você pode fazer por um número representativo. O que um benchmark de navegador consegue e não consegue medir trata do que fazer com o número depois que você o tem.