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.2.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 16,67 ms × 1,15.

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 é a rede de segurança que impede que falhas raras mas enormes passem só na contagem.

Por que o limiar 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. Sob as tolerâncias de média e P95 da 2.1.0, essa diferença deixava telas adaptativas passearem a 55 fps e serem aprovadas, enquanto monitores de 60 Hz tinham de sustentar 60 de verdade — a mesma GPU pontuava menos numa mesa do que na tampa de um notebook. Por isso, antes da primeira cena, uma sondagem de cadência de cerca de 600 ms observa como sua tela devolve quadros, e o critério se ajusta para que “sustenta 60 fps” seja a mesma afirmação em qualquer classe de tela. 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). Mandar a aba para segundo plano pausa a medição e invalida a janela atual; redimensionar reconstrói a cena e reaquece. 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 e confirmadas, mas o aparelho esquentou e desacelerou — 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, ou um nível que a busca nunca conseguiu confirmar — são um piso e não um pico, então ficam fora do ranking. Elas continuam guardadas, continuam contando nas medianas agregadas, 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.