GIF nhanh nhất không tồn tại

• Để đặt tốc độ GIF động nhanh nhất có thể, cần đặt "Frame Delay" là "20ms" chứ không phải "10ms". Tại sao lại như vậy?
• Từ GIF 89a, hỗ trợ ảnh động bắt đầu xuất hiện
  • Có thể đặt độ trễ cho từng khung hình
  • Thời gian chờ trước khi chuyển sang khung tiếp theo được biểu diễn theo đơn vị 1/100 giây (10ms)
  • Có thể đặt từ 0 ~ 0xffff (độ trễ khoảng 10 phút)
• Điều gì xảy ra nếu đặt là 0? Đặc tả không đưa ra câu trả lời chính xác, nhưng có nêu rõ hai điều
  • Khi giải mã GIF, mỗi khung hình phải được xử lý không có độ trễ
  • Giá trị độ trễ chỉ được dùng khi nó khác 0
  • Nói cách khác, nếu đặt là 0 thì nó phải được xử lý như "ảnh tĩnh được kết hợp với khung trước đó"
    • Khi đó có thể chèn các khung chỉ lưu phần chuyển động để giảm kích thước
• Vấn đề là không ai hỗ trợ độ trễ 0
  → Hầu hết các chương trình hỗ trợ GIF đều ép các giá trị từ 2 (20ms) trở xuống lên mức cao hơn
  • QT khớp với IE/FF : (delay < 2 ? 10: delay) * 10
  • Chrome khớp với FF : để ngăn các quảng cáo nhấp nháy dùng giá trị 0, các giá trị đặt từ 10ms trở xuống sẽ bị đổi thành 100ms
  • FF khớp với IE và Opera : nếu là 0~10 thì điều chỉnh thành 100ms
  • IE 5 khớp với Netscape vì Netscape chậm : nếu từ 50 trở xuống thì cố định ở 100
• Điểm chung của các đoạn mã trên là không chỉnh 0~1 thành 2, mà chỉnh thành 10 (100ms)
  • Tức là 10 giống như 100, và 20 là nhanh nhất

Kết luận

• Không ai đang render GIF đúng theo đặc tả, nhưng có lẽ nên làm vậy (IMO)
• Hiện tại, để có GIF nhanh nhất thì hãy đặt 2 (20ms) thay vì 1 (10ms)
• Nếu mọi người đều triển khai đúng đặc tả GIF
  • Có thể hỗ trợ GIF có độ trễ 10ms
  • Hỗ trợ hơn 256 màu trong một khung hình đơn của ảnh động GIF
  • Loại bỏ sự khó hiểu rằng đặt độ trễ nhỏ lại khiến nó chậm hơn
  • Có thể tạo GIF chỉ chứa vùng được cập nhật ở mỗi khung để cải thiện tỷ lệ nén