- अगर animated GIF की speed को अधिकतम तेज़ करना हो, तो "Frame Delay" को "10ms" नहीं बल्कि "20ms" पर सेट करना चाहिए। ऐसा क्यों?
- GIF 89a से animation support शुरू हुआ
- हर frame के लिए delay सेट किया जा सकता है
- अगले frame पर जाने से पहले इंतज़ार का समय 1/100 सेकंड (10ms) की इकाइयों में व्यक्त किया जाता है
- 0 ~ 0xffff (लगभग 10 मिनट के delay) तक सेट किया जा सकता है
- अगर 0 सेट करें तो क्या होगा? Spec में इसका सटीक जवाब नहीं है, लेकिन दो बातें स्पष्ट हैं
- GIF decoding के समय हर frame को बिना delay के process किया जाना चाहिए
- delay value का उपयोग सिर्फ तब होता है जब वह 0 न हो
- यानी, 0 सेट करने पर इसे "पिछले frame के साथ मिलाकर static image की तरह process" किया जाना चाहिए
- इससे सिर्फ हिलने वाले हिस्से को store करने वाले frame डालकर size घटाया जा सकता है
- समस्या यह है कि 0 delay को practically कोई support नहीं करता
→ GIF support करने वाले ज़्यादातर programs, 2 (20ms) या उससे कम values को उससे बड़े मान पर fix कर देते हैं
- QT, IE/FF के हिसाब से चलता है:
(delay < 2 ? 10: delay) * 10
- Chrome, FF के हिसाब से चलता है: blinking ads को 0 इस्तेमाल करने से रोकने के लिए, 10ms या उससे कम पर सेट किए गए मानों को 100ms बना देता है
- FF, IE और Opera के हिसाब से चलता है: 0~10 होने पर 100ms में adjust करता है
- IE 5, Netscape के हिसाब से चला क्योंकि वह धीमा था: 50 या उससे कम होने पर 100 पर fix
- ऊपर के code की समान बात यह है कि वे 0~1 को 2 पर नहीं, बल्कि 10 (100ms) पर ले जाते हैं
- यानी, 10, 100 के बराबर है, और 20 सबसे तेज़ है
निष्कर्ष
- कोई भी GIF spec के मुताबिक render नहीं कर रहा, लेकिन शायद ऐसा होना चाहिए (IMO)
- अभी के लिए, सबसे तेज़ GIF पाने के लिए 1 (10ms) की जगह 2 (20ms) सेट करें
- अगर सब लोग GIF spec को सही तरह implement करें
- 10ms delay वाले GIF को support किया जा सकेगा
- GIF animation के single frame में 256 से अधिक colors support हो सकेंगे
- छोटे delay value देने पर animation धीमा हो जाने वाली उलझन खत्म हो जाएगी
- सिर्फ प्रति-frame updated area वाले GIF बनाकर compression बेहतर की जा सकेगी
अभी कोई टिप्पणी नहीं है.