- หากต้องการให้แอนิเมชัน GIF เล่นได้เร็วที่สุด ต้องกำหนด "Frame Delay" เป็น "20ms" ไม่ใช่ "10ms" แล้วทำไมถึงเป็นแบบนั้น?
- ตั้งแต่ GIF 89a เป็นต้นมา จึงเริ่มรองรับแอนิเมชัน
- สามารถตั้งค่าดีเลย์ของแต่ละเฟรมได้
- ใช้หน่วยเป็น 1/100 วินาที (10ms) เพื่อบอกเวลาที่ต้องรอก่อนข้ามไปเฟรมถัดไป
- ตั้งค่าได้ตั้งแต่ 0 ~ 0xffff (ดีเลย์ได้ประมาณ 10 นาที)
- ถ้าตั้งค่าเป็น 0 จะเกิดอะไรขึ้น? ในสเปกไม่มีคำตอบที่ชัดเจน แต่ระบุไว้ 2 ข้อ
- ตอนถอดรหัส GIF แต่ละเฟรมต้องถูกประมวลผลโดยไม่มีดีเลย์
- จะใช้ค่าดีเลย์ก็ต่อเมื่อค่าไม่เป็น 0 เท่านั้น
- กล่าวคือ หากกำหนดเป็น 0 ก็ควรถูก "รวมกับเฟรมก่อนหน้าและประมวลผลเป็นภาพนิ่ง"
- แบบนี้สามารถใส่เฟรมที่เก็บเฉพาะส่วนที่เคลื่อนไหวเพื่อลดขนาดไฟล์ได้
- ปัญหาคือไม่มีใครรองรับดีเลย์ 0 เลย
→ โปรแกรมส่วนใหญ่ที่รองรับ GIF จะบังคับค่าที่ต่ำกว่า 2 (20ms) ให้เป็นค่าที่มากกว่านั้น
- QT ปรับให้ตรงกับ IE/FF : (delay < 2 ? 10: delay) * 10
- Chrome ปรับให้ตรงกับ FF : เพื่อป้องกันโฆษณากระพริบที่ใช้ค่า 0 ค่าที่กำหนดต่ำกว่า 10ms จะถูกตั้งเป็น 100ms
- FF ปรับให้ตรงกับ IE และ Opera : ถ้าเป็น 0~10 จะปรับเป็น 100ms
- IE 5 ปรับให้ตรงกับ Netscape เพราะฝั่งนั้นช้า : ถ้าต่ำกว่าหรือเท่ากับ 50 จะถูกล็อกเป็น 100
- จุดร่วมของโค้ดเหล่านี้คือไม่ได้ปรับ 0~1 ให้เป็น 2 แต่ปรับเป็น 10 (100ms)
- นั่นคือ 10 เท่ากับ 100 และ 20 เร็วที่สุด
บทสรุป
- ไม่มีใครเรนเดอร์ตามสเปก GIF เลย แต่ดูเหมือนควรจะทำแบบนั้น (IMO)
- ตอนนี้ถ้าอยากได้ GIF ที่เร็วที่สุด ให้กำหนดเป็น 2 (20ms) แทน 1 (10ms)
- หากทุกคนทำตามสเปก GIF อย่างถูกต้อง
- ก็จะรองรับ GIF ที่มีดีเลย์ 10ms ได้
- รองรับมากกว่า 256 สีในเฟรมเดี่ยวของแอนิเมชัน GIF
- ลดความสับสนที่ยิ่งตั้งค่าดีเลย์ต่ำกลับยิ่งช้าลง
- สามารถสร้าง GIF ที่มีเฉพาะพื้นที่ที่อัปเดตในแต่ละเฟรมเพื่อเพิ่มอัตราการบีบอัดได้
ยังไม่มีความคิดเห็น