fbpx
18.9 C
София

Не съществува понятие като най-бързият GIF

Оригиналът е на biphelps.com

Най-четени

Даниел Десподов
Даниел Десподовhttps://www.kaldata.com/
Ежедневен автор на новини. Увличам се от съвременни технологии, оръжие, информационна безопасност, спорт, наука и концепцията Internet of Things.

Проблемът на GIF изображенията

Представете си, че просто на шега искате да създадете GIF файл, в който изображението се променя по някакъв по-интересен начин, като например следния:

За да получите нещо подобно навярно задавате минимално възможното значение на продължителността и забавяне на кадъра. Но при прегледа на това GIF изображение ще видите, че то се възпроизвежда много по-бавно от замисленото, като вие със сигурност сте искали да видите един по-бърз GIF. Какво всъщност става?

Ако четете този материал и търсите съвсем кратък и ясен отговор, то решението е следното: поставете таймаута не на 10 ms, а на 20 ms. Ако искате да разберете защо се налага да се прави това, продължавайте да четете.

(Забележка: ако четете тази статия от далечното утопично бъдеще, когато това вече не е проблем, то някои от показаните GIF изображения може да ви се сторят неособено разбираеми. В противен случай, моите съболезнования – можете да не обръщате внимание на това пояснение).

Ставам ето такъв, когато моите GIF са твърде бавни

Особеностите на GIF

Няма да разглеждаме цялата структура на един GIF файл. Това може да бъде прочетено например в материала What’s in a GIF на Матю Флинкър.

В първата версия (87а) на GIF формата имаше възможност няколко кадъра с различни размери и разположение да бъдат наредени последователно и да образуват едно подвижно изображение. Всеки кадър можеше да има собствена палитра от 256 цвята, което означава, че това изображение не може да има повече от 256 уникални цвята.

В сегашната версия (89а) на GIF формата се поддържат анимация и прозрачност. Сега пред всеки кадър може да бъде зададено незадължително забавяне, което определя колко дълго да се показва съответния кадър преди да излезе следващият. По-конкретно, това е броят на стотните от секундата, които показват колко трябва да се изчака преди да бъде показан следващия кадър. Възможно е задаване на значения от 0 (без забавяне) до 0hFFFF (около 10 минути).

GIF със забавяне на кадъра 5 (50 ms)
Същият GIF със забавяне 50 (500 ms)

Без забавяне

Какво ще се види на екрана, ако сме задали значение на забавянето да е 0? Спецификацията на този формат не отговаря пряко на този въпрос, като само се споменават два аспекта:

  1. Ори декодирането на GIF изображенията всеки кадър трябва да се обработва без каквото и да било забавяне с изключение на кадрите, за които е зададена тази изкуствена латентност
  2. Забавянето се взема предвид само ако неговото значение не е равно на 0

Според мен, тези обяснения означават, че всички кадри с латентност 0 трябва да се комбинират с латентността от предишния кадър на изображението, понеже именно по този начин работеше  първият GIF формат версия 87а. Ако за всички кадри на даден GIF файл са зададени нули (0), то в крайна сметка ще се получи статично изображение, което включва всичката информация от всичките кадри.

Ето два примера, които показват как изглеждат GIF изображенията, при условие, че спецификацията е спазена:

Статичен GIF файл с много повече от 256 цвята, който показва информацията от всичките кадри

Анимация с червени квадрати, забавянето на които е 0. Тези червени квадрати тук не се виждат

За да станат по-ясни протичащите процеси нека да покажем как става рендирането на по-горните GIF изображения:

Многоцветният GIF файл рендира изображението на малки стъпки – само неголяма част наведнъж

Така става рендирането на втория файл. Червените квадрати с латентност 0 се виждат за малко

Проблемите

Основният проблем е в това, че никой не поддържа таймаут (забавяне) равен на 0. И наистина, нито една програма, с които обикновено преглеждате GIF файловете (Firefox, Edge, IE, Chrome, Windows Explorer, Electron и Qt), не може да покаже GIF с подобно забавяне. Всичкият този софтуер когато срещне забавяне под 2 (20 ms), автоматично променя забавянето на 2/над 20 милисекунди. Ако прегледаме набързо сорс кода на някои от тези програми може да разберем какво се случва.

Qt (версия 6.2.2)

Кодът по-горе  е от Qt. В коментарите е написано, че:

„IE и mozilla поддържат минимално значение 10 на това забавяне. При забавяне 10 ние сме съвместими с всичко и избягваме огромните натоварвания на приложението и на xserver“.

Chromium (версия 98.0.4754)

Част от сорс кода на Chromium:

„Почти при всички твърде дразнещи банери е поставено забавяне 0, за да може изображението да примигва колкото се може по-бързо. Ние копираме поведението на Firefox и използваме забавяне от 100 ms за всички кадри при които забавянето е зададено <= 10 ms“.

Firefox (версия 97)

Сорс кодът на Firefox:

„Твърде малките значения на таймаута са проблематични поради две причини: ние не искаме да харчим излишна енергия за твърде бързото прерисуване на анимираните изображения. Некачествените софтуерни инструменти генерират подобни значения, като в същото време на тях им е нужно значението, което се използва по подразбиране. Ето защо за тези изображения се налага да се използва нормализация… От историческа гледна точка поведението на IE е следното: забавянето в рамките на 10-50 ms се нормализира до 100 ms. Когато забавянето е >50 ms, то се използва без да се прави нормализация“.

Сорс кодът на по-стара версия на Firefox:

„Осигуряваме минимално време между обновяванията на кадъра, за да не може да се предизвиква тротлинг на потока UI. Считаме 0 == за неопределено значение и в този случай правим анимацията бърза, но не много бърза… Изглежда се използват некачествени софтуерни инструменти, които задават таймаут 0 ms или 10 ms, въпреки че всъщност им е необходимо значението по подразбиране. Ето защо ние променяме значенията от този диапазон“.

Internet Explorer 5

Сорс кодът на Internet Explorer 5 е затворен, но хипотетично би изглеждал по следния начин:

Хипотетичният сорс код на Internet Explorer 5:

„Грубо хакване за обработването на ненормалните анимации, задръжката на които е твърде ниска поради латентностите в процеса на анимиране на Netscape, Тези малки значения на таймаута са зададени, за да може анимацията да изглежда сравнително добре в твърде бавния Netscape“.

От натрупаната информация можем да направим следните изводи:

  • Qt нормализира таймаута, за да се постигне еднаквост на анимацията при IE и Firefox, както и за да се избегне прекомерното натоварване на процесора
  • Chromium прави същото, за съответства на поведението на Firefox и за да премахне дразнещите и бързо примигващи банери
  • Firefox прави това, за да съответства на поведението на IE и Opera, както и за да избегне претоварването на процесора
  • IE 5 прави това, понеже Netscape бе твърде бавен и заради това хората създаваха зле форматирани GIF изображения

Но във всичко това се забелязва нещо твърде странно: вместо значението на този таймаут да се увеличи до 1 или 2, всички увеличават това значение чак до 10 (100 ms). А това означава, че ако се зададе прекалено малко забавяне, ще се получи сравнително бавен GIF файл. Но ако това забавяне се зададе да бъде малко по-високо, то GIF изображението става много по-бързо.

10 ms
20 ms
50 ms
100 ms

Ако във вашия браузър декодирането на GIF изображенията е невярно, то единият от по-горните GIF файлове ще бъде с неправилна скорост.

Размисли

По всичко личи, че причината за увеличаването на таймаута в зоната до 10 веднага на 100 се дължи на усилията на програмистите да имитират бавния Netscape. Но разработчиците е трябвало да се спрат на 20 ms, понеже всички съвременни браузъри без проблем рендират GIF кадри със забавяне 20 ms, а и аргументът, че компютрите са твърде бавни, не важи след цели 30 години.

Освен това, според мен трябва да бъдат оставени и кадрите със забавяне 0. Нека се комбинират със значението от предишния кадър. Ще се получи изображение, съдържащо всички кадри, но това е един интересен ефект, който е еднакъв при всички браузъри и не води до натоварване на процесора. По принцип, точно такава е спецификацията на GIF формата.

Лично аз бих искал да направя две отделни неголеми области в големите GIF файлове, за да може да бъде намален техния размер. Сега за да се направи това е необходимо да се намери правоъгълна област, която обхваща всички промени на изображението, и от нея да се направи оптимален GIF файл. Но ако можеха да се вземат няколко кадъра и всичките, освен един от тях да имат значение 0, то ще се получи същия ефект, но с по-малко данни на изображението:

Едната от тези области може да бъде зададена като кадър с таймаут 0 о по този начин да бъде създаден много по-оптимизиран GIF файл.

Само че това няма как да стане, понеже внасянето каквито и да било промени от подобен род водят до това, че браузърите считат подобен файл за зле форматиран GIF, който изобщо не се рендира. Показва се само празна рамка без изображение.

Да проверим все пак какво прави Netscape

Дали как изглежда рендирането на GIF изображение в Netscape 2.0? По-долу е даден същият тестов GIF с червените квадрати, който се показва правилно от Netscape 2.0 в средата на Windows 95:

А сега GIF със забавяне 2 (20 ms). Резултатът е твърде неочакван – всичко работи много бавно, но ако размърдаме мишката процесът се ускорява до нормалното. Проблемът е отдавна познат и е много добре описан в Stack Overflow.

Ето как изглежда GIF файлът с таймаут 0. Интересно е, но си нямам понятие защо за ускоряване на процеса не се налага да мърдам мишката.

И ето го GIF файлът с таймаут 10 ms, който така дълго чакахме…

А така. Първоначално се забавя, а след това крашва. Изглежда никой никога не е успял да види в своя браузър GIF със забавяне 10 ms. Сриването на Netscape е един твърде зловещ знак и не се знае какво би станало, ако някой твърде упорито бе търсил най-бързото GIF изображение.

 Изводи

Никой не рендира GIF изображенията според спецификациите, а според мен трябва. А засега, за да се получи най-бързия GIF е необходимо таймаутът да е зададен да бъде 2 (20 ms), а не 1 (10 ms).


Коментирайте статията в нашите Форуми. За да научите първи най-важното, харесайте страницата ни във Facebook, и ни последвайте в Telegram и Viber или изтеглете приложението на Kaldata.com за Android, iOS и Huawei!

Абонирай се
Извести ме за
guest

11 Коментара
стари
нови
Отзиви
Всички коментари

Нови ревюта

Подобни новини