- Para deixar a velocidade de um GIF animado o mais rápida possível, é preciso definir o "Frame Delay" como "20ms", e não "10ms". Por quê?
- O suporte a animação começou no GIF 89a
- É possível definir um atraso para cada frame
- O tempo de espera antes de passar para o próximo frame é expresso em unidades de 1/100 de segundo (10ms)
- Pode ser configurado de 0 a 0xffff (cerca de 10 minutos de atraso)
- O que acontece se definir 0? A especificação não dá uma resposta exata, mas deixa duas coisas claras
- Na decodificação de GIF, cada frame deve ser processado sem atraso
- O valor de atraso só é usado quando não é 0
- Ou seja, se for definido como 0, ele deve ser "combinado com o frame anterior e tratado como uma imagem estática"
- Isso permite inserir frames contendo apenas as partes que se movem para reduzir o tamanho
- O problema é que ninguém oferece suporte a atraso 0
→ A maioria dos programas que suportam GIF fixa valores de 2 (20ms) ou menos para algo maior
- O QT se alinha ao IE/FF : (delay < 2 ? 10: delay) * 10
- O Chrome se alinha ao FF : para impedir que anúncios piscantes usem 0, valores definidos em 10ms ou menos viram 100ms
- O FF se alinha ao IE e Opera : no caso de 0~10, ajusta para 100ms
- O IE 5 se alinhou ao Netscape porque ele era lento : valores de 50 ou menos são fixados em 100
- O ponto em comum entre esses códigos é que, em vez de ajustar 0~1 para 2, ajustam para 10 (100ms)
- Ou seja, 10 é igual a 100, e 20 é o mais rápido
Conclusão
- Ninguém está renderizando de acordo com a especificação do GIF, mas deveria (IMO)
- No estado atual, para obter o GIF mais rápido, use 2 (20ms) em vez de 1 (10ms)
- Se todos implementarem corretamente a especificação do GIF
- Será possível dar suporte a GIFs com atraso de 10ms
- Suporte a mais de 256 cores em um único frame de animação GIF
- Acabar com a confusão de que atrasos pequenos deixam a animação mais lenta
- Será possível criar GIFs com apenas a área atualizada por frame, melhorando a taxa de compressão
Ainda não há comentários.