Comparação de mercado de gráficos do navegador em poucas palavras: renderize o máximo possível mantendo uma taxa de quadros suave. Quando a taxa de frames cai, você sabe quanto pode desenhar por frame. Fim da postagem. Não? Ok, vou explicar melhor.
Exemplo de tempo! Confira um pequeno snippet de código com uma função tick de comparação. A função tick chama uma função draw com uma carga de exibição cada vez maior até que a exibição leve mais de 33 ms.
var t, previousTime;
var drawLoad = 1;
var slowCount = 0;
var maxSlow = 10;
// Note, you might need to polyfill performance.now and requestAnimationFrame
t = previousTime = performance.now();
var tick = function() {
var maximumFrameTime = 1000/30; // 30 FPS
t = performance.now();
var elapsed = t - previousTime;
previousTime = t;
if (elapsed < maximumFrameTime || slowCount < maxSlow) {
if (elapsed < maximumFrameTime) {
drawLoad+=10;
} else {
slowCount++;
}
draw(drawLoad);
requestAnimationFrame(tick);
} else {
// found maximum sustainable load at 30 FPS
document.getElementById('res').innerHTML = ("could draw "+(drawLoad)+" in " +
maximumFrameTime + " ms");
}
};
requestAnimationFrame(tick);
Confira o exemplo em tempo real no jsFiddle.
Você pode ver como o comparativo continua aumentando até chegar ao ponto em que ele desacelera. Essa é uma maneira simples e legal de descobrir quanto você pode desenhar com uma taxa de frames suave. Você também pode conectar sua própria função de desenho ao exemplo e fazer alguns comparativos personalizados.
Considerações e armadilhas comuns ao comparar gráficos de navegadores
Se o exemplo acima é a melhor maneira de fazer isso, quais são as maneiras não tão boas? As maneiras que levam você a comparar coisas não relacionadas ou que fornecem métricas de desempenho estranhas que não parecem ter nada a ver com a velocidade de execução do app. Que bom que você perguntou. Aqui estão as duas mais comuns que encontrei na Web.
Medir o QPS máximo: desenhe um pouco em cada frame e meça o QPS. Ele não funciona bem para medir o desempenho gráfico no Chrome porque a implementação gráfica subjacente é sincronizada com a taxa de atualização da tela, ou seja, você recebe no máximo 60 atualizações de tela por segundo. Medir a velocidade da chamada de desenho não será muito útil, já que o sistema de exibição do Chrome coloca seus comandos de exibição em um buffer de comando que é executado na próxima atualização da tela.
Usar setTimeout para medir a performance gráfica é outra ideia ruim. O intervalo setTimeout é limitado a 4 ms nos navegadores, então o máximo que você pode conseguir é 250 QPS. Historicamente, os navegadores tinham intervalos mínimos diferentes. Por isso, você pode ter um comparativo de mercado muito ruim que mostrava o navegador A rodando a 250 QPS (intervalo mínimo de 4 ms) e o navegador B rodando a 100 QPS (intervalo mínimo de 10 ms). Claramente, A é mais rápido! Não! É possível que B tenha executado o código de exibição mais rápido que A. Digamos que A levou 3 ms e B levou 1 ms. Isso não afeta os QPS, já que o tempo de exibição é menor que o intervalo mínimo de setTimeout. E se o navegador renderizar de forma assíncrona, tudo estará perdido. Não use setTimeout a menos que você saiba o que está fazendo.
Como fazer isso
Uma maneira melhor de comparar é usar uma carga de renderização realista e multiplicá-la até que a taxa de frames comece a falhar. Por exemplo, se você estiver escrevendo um jogo de cima para baixo com um terreno de mapa de tiles, tente desenhar o mapa de tiles em cada frame e conferir se ele é executado a 60 QPS. Se sim, aumente a carga (desenha o mapa de blocos duas vezes em cada frame, com uma limpeza entre eles). Continue aumentando até que os QPS caiam para um novo nível estável. Agora você sabe quantas camadas de mapa de blocos podem ser renderizadas por frame.
Diferentes aplicativos gráficos têm necessidades diferentes. Portanto, crie seus parâmetros de comparação pensando nisso. Meça os recursos gráficos que você está usando no app. Quando encontrar um cenário lento, tente reduzi-lo ao menor trecho de código que o reproduz. Se ele precisa ser mais rápido, envie um relatório de bug em new.crbug.com.
Para saber como escrever código de gráficos da Web de alto desempenho, confira a palestra do Google I/O 2012 de Nat Duca e Tom Wiltzius, da equipe de GPU do Chrome.