Teste de Taxa de Quadros

Um teste de taxa de quadros mede quantas imagens um dispositivo entrega por segundo e com que uniformidade essas imagens chegam. Este teste amostra o carimbo de tempo que o navegador associa a cada quadro de animação e converte o intervalo entre quadros consecutivos em uma taxa de quadros em FPS. A partir dessas amostras ele informa seis números: o contador ao vivo, a média, o mínimo, o 1% low, o desvio padrão dos intervalos entre quadros e uma contagem de travamentos. A média descreve a vazão, enquanto os outros cinco descrevem a consistência, e é por isso que são informados separadamente. Um único número médio não consegue dizer se uma medição foi fluida ou cheia de engasgos.

Garanta que esta aba seja a janela ativa, porque os navegadores limitam os quadros de animação nas abas em segundo plano e a leitura desaba para uma taxa simbólica. Feche os aplicativos pesados, clique em Iniciar Teste e deixe o contador rodando por pelo menos dez segundos, quando a medição é concluída automaticamente e o painel de diagnóstico a pontua. Observe a média se estabilizar primeiro, compare-a com o 1% low logo abaixo e leia por último a variação do tempo de quadro e a contagem de travamentos. Para uma comparação justa, rode o teste três vezes em condições idênticas e compare a dispersão em vez de confiar em uma única leitura, já que uma medição isolada é facilmente distorcida por uma atualização em segundo plano.

O 1% low pega os 1 por cento de quadros mais lentos de uma medição, faz a média dos tempos de quadro e converte isso de volta em taxa de quadros. Ele responde à pergunta que a média não consegue responder: quão ruins são os momentos ruins? Se a média é 120 FPS mas o 1% low é 45 FPS, então cerca de um quadro em cada cem leva mais que o triplo do que deveria, e essas travadas são exatamente o que os jogadores percebem como engasgos e comandos perdidos. Como regra prática, um sistema saudável mantém o 1% low dentro de cerca de 10 a 20 por cento da sua média, e qualquer diferença maior aponta para um problema de ritmo e não de velocidade bruta.

Para trabalho no desktop, vídeo e navegação, 60 FPS é confortavelmente fluido porque corresponde à taxa de atualização da maioria das telas. Para jogos, 60 FPS é jogável, 120 FPS dá uma melhoria clara na clareza de movimento e na resposta aos comandos, e 240 FPS beneficia principalmente jogadores competitivos que também têm um painel de alta taxa de atualização equivalente. Acima da taxa de atualização do seu painel, quadros extras são em grande parte descartados, então um resultado de 90 FPS em uma tela de 60Hz acrescenta fluidez sobretudo pela redução do tearing e não por quadros extras visíveis. A consistência importa mais que o pico, e 60 travados com um 1% low de 55 se sentem melhor que uma média de 90 com um 1% low de 30.

O travamento quase sempre vem de tempos de quadro irregulares e não de uma média insuficiente. A causa mais comum é a carga em segundo plano: um segundo monitor reproduzindo vídeo, uma aba do navegador decodificando uma página pesada, um cliente de sincronização na nuvem ou uma atualização do sistema roubam tempo de CPU e GPU em rajadas. A segunda causa comum é o gerenciamento térmico ou de energia, já que notebooks na bateria e chassis finos sob carga sustentada reduzem os clocks, e é por isso que uma medição costuma começar rápida e degradar em um minuto. A terceira é um limite de taxa de quadros combinado com uma taxa de atualização incompatível, em que o VSync e um limite de 60 FPS em um painel de 60Hz brigam entre si e produzem judder visível.

Ele é preciso para o que mede, que é a taxa de quadros que o pipeline de renderização do navegador realmente entrega à tela, e é a ferramenta correta para uma aplicação web, um jogo de navegador ou uma cena de canvas e WebGL. Cada quadro recebe carimbo de tempo do próprio navegador, então os intervalos são reais e não estimados. Os limites são de escopo e não de precisão: o navegador não consegue ler o contador interno de FPS de um jogo nativo em outra janela, não consegue informar uso de GPU nem frequência de clock e não consegue medir a latência de clique a fóton. Ele também não pode ser um benchmark de hardware puro, porque tanto o sistema operacional quanto o navegador adicionam carga própria.

Eles medem duas coisas diferentes que são fáceis de confundir. Um teste de taxa de atualização mede o teto do painel: quantas vezes por segundo a tela consegue fisicamente redesenhar, tipicamente 60, 120, 144 ou 240 vezes, e também verifica ghosting e salto de quadros. Um teste de taxa de quadros mede o que está de fato sendo entregue dentro desse teto. A relação importa: se o seu painel é 144Hz mas a taxa de quadros entregue é 60, a tela não é o gargalo de forma alguma e trocá-la não mudaria nada. Rode o teste de taxa de atualização para estabelecer o teto e depois o teste de taxa de quadros para ver quanto desse teto você está realmente usando.

Percorra as causas em ordem de probabilidade. Primeiro feche outras abas, chamadas de vídeo e launchers, e rode o teste de novo para ver quanto da queda era carga em segundo plano. Segundo, verifique o uso de CPU e GPU durante a medição, porque um único núcleo saturado ou uma fila gráfica ocupada normalmente explica um 1% low baixo. Terceiro, mude o perfil de energia do sistema operacional de um modo de economia para equilibrado ou alto desempenho, o que importa mais em notebooks na bateria. Quarto, atualize o driver de vídeo e confirme que um notebook com gráficos híbridos está usando a GPU dedicada. Por fim, reduza a carga de renderização da página que você está medindo.

Você pode testar qualquer jogo que rode dentro da aba do navegador, incluindo títulos HTML5, canvas, WebGL e WebGPU, porque eles são desenhados pelo mesmo pipeline de quadros de animação que este teste amostra. Você não pode testar um jogo nativo rodando em outra janela ou em modo exclusivo de tela cheia, porque uma página web não tem acesso ao interior de outro aplicativo. Para jogos nativos, use a sobreposição de FPS embutida do jogo ou do driver de vídeo, por exemplo a sobreposição de desempenho do NVIDIA GeForce Experience ou do AMD Adrenalin. Use este teste para jogos de navegador e aplicações web e use essas sobreposições quando precisar de telemetria dentro do jogo.

O tempo de quadro é quanto tempo um único quadro leva, medido em milissegundos, enquanto o FPS conta quantos quadros cabem em um segundo. Os dois são inversos matemáticos: 60 FPS equivalem a 16.7 milissegundos por quadro, 120 FPS a 8.3 e 144 FPS a 6.9. Ao caçar travamentos, o tempo de quadro é o número mais revelador, porque descreve cada quadro individualmente em vez de médiar um segundo inteiro. Uma medição com média de 60 FPS ainda pode conter quadros de 40 milissegundos ou pior, e são esses quadros longos que o olho lê como engasgo. Este teste informa o tempo de quadro diretamente, tornando visíveis os valores discrepantes que um contador simples esconde.

Uma média alta com tempos de quadro instáveis parece pior que uma menor, porém constante, pois o olho sente muito mais a variação de ritmo que a velocidade absoluta. Se a média é 144 FPS, mas cada décimo quadro leva 30 milissegundos, o movimento mostra judder visível apesar da média saudável. Causas típicas: um núcleo de CPU saturado, compilação de shaders travada, um engasgo no streaming de texturas ou um processo em segundo plano disputando a GPU. A verificação prática é observar o 1% low e a contagem de travamentos, não a média: um 1% low a 10 a 20 por cento da média indica ritmo saudável, e uma diferença maior aponta um gargalo de picos, não de desempenho bruto.

Um limite de taxa de quadros restringe quantos quadros o aplicativo tem permissão de produzir, normalmente para manter a saída alinhada com a tela. Limitar um pouco abaixo da taxa de atualização do painel, por exemplo 141 FPS em uma tela de 144Hz com o VSync ativado, é a forma padrão de cortar a latência de entrada e evitar o tearing. Em uma tela de taxa de atualização variável, como G-Sync ou FreeSync, um limite abaixo do máximo mantém o painel dentro da sua faixa variável e impede que ele volte ao comportamento de taxa fixa. O limite só se torna prejudicial quando é definido, sem motivo, abaixo do que o sistema poderia entregar, deixando desempenho real sem uso.