Polling rate do controle: o limite do navegador

Escreva “controller polling rate test” num motor de busca e encontrará uma dúzia de páginas que lhe darão um número em Hz. Execute dois deles no mesmo comando e é bem provável que obtenha duas respostas diferentes. Execute um deles num portátil de 60 Hz e depois num monitor de 144 Hz, com o mesmo comando, e obterá duas respostas muito diferentes.

O número não é aleatório. É a sua taxa de atualização.

O mecanismo, num parágrafo

Um navegador não recebe input de comandos como eventos. Não existe oncontrollermove. Uma página pede navigator.getGamepads()para o estado atual, e o local sensato para perguntar é dentro da chamada de retorno de animação — a função que o navegador executa uma vez por fotograma desenhado. Assim, uma página pode observar no máximo uma alteração de estado por fotograma. A 60 fps isso são sessenta observações por segundo, a 144 fps cento e quarenta e quatro, e não faz diferença se o comando subjacente está a reportar a 125 Hz ou 1000 Hz.

Tudo o que se segue decorre desse único facto.

Porque é que o número continua a indicar-lhe algo

Uma leitura limite não é inútil. É um valor mínimo: o seu comando está a acompanhar o seu ecrã, que é a parte que chega ao jogo. Um fotograma que não tivesse novos dados do comando seria um fotograma em que a sua vista não rodaria, e é exatamente isso que não tem.

O que não consegue fazer é distinguir entre um comando que está confortavelmente à frente do seu ecrã e um que está apenas a conseguir acompanhar. Ambos apresentam a mesma leitura.

Quando o número é real

Se a leitura fica claramente abaixoda sua taxa de atualização, o comando é o mais lento dos dois e o valor é uma medição genuína. Isto é comum em Bluetooth e é o caso em que vale a pena agir — alguns fotogramas do seu jogo vão reutilizar a posição anterior do manípulo porque não chegou nada mais recente.

Essa é toda a árvore de decisão:

• No teto— nada para corrigir aqui. Um cabo não consegue elevar um número que o navegador nunca conseguiu ultrapassar.
• Abaixo do teto— o comando é o limite. Vale a pena repetir por cabo, porque o mesmo comando com fio normalmente reporta dados muito mais rapidamente do que por Bluetooth.

O que as tabelas de referência significam

A maioria das páginas de polling rate imprime uma tabela como esta:

Esses valores vêm dos protocolos, não de um navegador, e são um contexto útil. Mas repare no que a tabela significa em conjunto com o mecanismo acima: num ecrã de 144 Hz,todas as linhas exceto Bluetooth-Xbox estão acima do seu teto. Um navegador não consegue distinguir nenhuma delas. A tabela descreve uma gama de hardware que um teste de navegador comprime numa única resposta.

Porque é que o seu manípulo tem de estar em movimento

Um comando que está parado pode deixar de enviar pacotes completamente — não há nada para reportar e o silêncio poupa bateria. Um teste que contasse alterações de estado enquanto mantém as mãos paradas estaria a medir a taxa em ócio e a chamar-lhe o polling rate.

Portanto, qualquer versão honesta deste teste pede-lhe para rodar os manípulos durante toda a amostra. Se vir um número suspeitosamente baixo, essa é a primeira coisa a verificar antes de concluir algo sobre o hardware.

O que isto significa para um jogo

Quase nada, e esta é a parte que os argumentos sobre Hz normalmente ignoram. Um jogo lê o seu comando no seu próprio ritmo — tipicamente uma vez por ciclo de simulação ou uma vez por fotograma — exatamente pela mesma razão que um navegador o faz. Um comando a reportar a 1000 Hz num jogo a correr a 120 fps está a enviar aproximadamente oito pacotes por leitura, sete dos quais são substituídos antes de qualquer coisa olhar para eles.

O argumento a favor de um comando mais rápido não é que o jogo veja mais deles. É que o pacote mais recente no momento da leitura é mais fresco: a 1000 Hz os dados têm no máximo um milissegundo, a 125 Hz podem ter oito. Essa é uma diferença real e pequena, e é uma afirmação diferente daquela que o número de Hz parece fazer.

Como obter um número que possa comparar

1. Meça na máquina em que joga efetivamente, com o ecrã que utiliza.
2. Anote a sua taxa de atualização ao lado do resultado. Uma leitura de comando sem ela não é interpretável.
3. Rode ambos os manípulos durante toda a amostra.
4. Repita uma vez. Uma única execução que discorde de outras duas é uma falha de temporização, não de hardware.
5. Se o número estiver abaixo da sua taxa de atualização, experimente um cabo e meça novamente. Se estiver no teto, não há nada aqui para melhorar.

O controller checkexecuta isto juntamente com o drift, intervalo do manípulo, botões e gatilhos, e imprime o teto ao lado da leitura. Oteste de input latencyreporta a mesma medição com a distribuição de intervalos por trás, o que é mais informativo do que qualquer um dos números isoladamente.

A versão curta

Um navegador pesquisa o estado de um comando uma vez por cada fotograma desenhado. Qualquer polling rate de comando fornecido por um navegador é limitado pela sua taxa de atualização, por isso uma leitura nesse teto significa “pelo menos tão rápido quanto isto, e esta página não consegue ver mais além”. Apenas uma leitura abaixo do teto é o número real do seu comando — e esse é o único que vale a pena tentar alterar.