Анімація падаючого снігу на Canvas ефективніше анімації на DOM в кілька разів

.В порівнянні з нативним JS на елементах DOM, реалізація анімаційних алгоритмів на Canvas зазвичай продуктивніше у багато разів. Це відомий факт (але з особливостями для малого числа частинок, як з'ясується пізніше), і він може знайти реалізацію так всім заважає традиційного під НГ, але гнаного раціональними користувачами «падаючого снігу». Щоб навантаження було мало, в останні роки вважається хорошим тоном «запускати» сніг на сайті ледь помітним, з мінімальною кількістю сніжинок (5-15). Тут і ефект є, і навантаження на процесор майже ніякої.

Тому, поки до НГ ще кілька днів ще зима, пропоную влаштувати хакатончик по реалізації кращих алгоритмів на канвасі та їх аналогів на DOM, взявши за основу давні нативні алгоритми, які як максимум обертывались в плагін jQuery, щоб було зручно підключати. Велика частина цих алгоритмів не вимірює навантаження на процесор або зроблена неефективно, тому навіть при малому числі сніжинок завантажують процесор на 100%. Ось приклад оглядової статті, де розглянуто більше 10 реалізацій, не все, що зустрічаються в природі. На додаток, розглянемо кілька обраних, щоб отримати перевагу на розвиток алгоритму та реалізацію його з гарною ефективністю (вийде ще 5-6 варіантів). На цій основі можна побудувати доопрацювання.

Як правило, життя статті на Хабре не триває більше 1.5 днів, тому не можна розраховувати акцію ефективною. Але після Нового Року трапляються різні дива: потік відвідувачів падає, і випадкові сновиди отримують шанс не забути одну статтю цілих 5 днів. На них і робиться ставка.

Краще якщо вона буде прив'язана до тривалого процесу, наприклад, до клубу Анонімних Дідів Морозів, заходячи в який завжди можна буде отримати прив'язку до обговорення та розвитку варіантів «падіння снігу» і при цьому він не прив'язаний жорстко до свята. Результат в даний час — тут: geekadm.ru/#/2015, і є, звичайно, проміжні експерименти типу 46.101.141.171/snow.html?v=4 — сніг для HabraAdm з додатковими ефектами.

Попередній «хакатон» був влаштований парою учасників і (або) відвідувачів клубу — (1), (2). В результаті, вийшло до 10 варіантів на движку з Canvas. Їх кількість може бути набагато більше, але на все потрібен вільний час, тому акція перетворилася у відкриту. Наприклад, можна «прикрутити» до движка вже написану в 2003 році модель падіння сніжинок автором Peter Gehrig. Доробка у 2005-2006 показує на сучасних браузерах, що 20-30 сніжинок незначно навантажує процесор (10-20%, залежить від потужності і відеокарти; тут і далі будемо говорити про завантаження одного ядра процесора, т. к. JS — однопотоковий), а за свідченнями старих форумів, подібне було і на старих браузерах типу Opera 9 і IE6, але дещо гірше. На Canvas з тим же алгоритмом можна було б запускати раз в 5 більше об'єктів.


демо


Заглянемо в історію і подивимося на її хід
Давайте почнемо з початку, з 2002-2005 років приблизно. Джаваскрипт показав здатність анімувати падіння сніжинок. Правда, виявилося, і це було природним, анімація на скрипті або непроизводительная, або сильно навантажує процесор. Тому і в ті старі часи потрібно було або дуже економити ресурси, або вантажити процесор по максимуму, на 100% в потоці браузера (на 1 ядрі) що гальмувало інші вкладки (в тих браузерах типу Опери 9, де вони були) і вікна, і це викликало погано приховане обурення відвідувачів таких сторінок.

Через 8 років знайшлося рішення цієї проблеми на рівні браузера. Основні браузери, починаючи з Хрому, стали припиняти виконання скриптів на невидимих вкладках. Це допомогло не заважати перегляду інших вікон і програм (але не призупиняється при переході на інше вікно, а тільки зменшується навантаження, якщо вікно не малюється на екрані або видно частково). Правда, у зв'язку з мобільного ерою, відкривання сторінок з грузовій анімацією, все одно не сприймається позитивно.

Але за ці роки з'явився і більш досконалий механізм анімації — Canvas. Відразу треба зауважити, що інший новаторський механізм анімації в CSS — не допомагають економити навантаження, і витрачають енергію процесора рівно стільки ж, як і анімація на Javascript + DOM. Тобто, якщо шукати найкраще рішення, то доводиться робити це в Canvas.

Canvas, як це буде видно на прикладах, дозволяє сотню сніжинок запустити з навантаженням 30-40% для середнього настільного комп'ютера або ноутбука. Це приблизно в 5 разів ефективніше, ніж вміють кращі оптимізовані алгоритми на JS+DOM.

Як данина історії, розглянемо і «класичні» алгоритми, які чекають свого часу для оптимізації і перекладу на Canvas.

Дуже багато алгоритмів легко знайти пошуком в Github за словами типу «snowfall js», «snow flakes js». Вони доповнять хорошу підбірку з 12 скриптів з демо-посиланнями, згадану вище або розширена копія).

Огляд алгоритмів з прикладами
(При перегляді сторінок з прикладами будьте готові іноді до 100%-ний завантаженню ядра процесора. При показі посилання в статті про рівень завантаження попереджається.)

Багато алгоритми, крім того, що неефективні, ще й не схожі по поведінці на реальну поведінку сніжинок. Напевно, багатьом пам'ятається, що впадає в очі невідповідність реальності рух сніжинок по синусоїді. Одного разу побачене або новіше), воно запам'ятовується надовго в якості негативного прикладу. Тому, завдання алгоритму — бути не тільки ефективним, але і відображає реальність. (По ефективності, обчислення гармонійних функцій теж має програвати.)

З раніше переглянутих алгоритмів найбільш близькими до реальності можна вважати два — з випадковими переміщеннями (варіювати треба швидкості, а не координати) і згаданий алгоритм Peter Gehrig (2003), в якому рух управляється 4 змінними, і одна з них — гармонійно змінюється, що створює періодичні ефекти «завихрень». Втім, із цього приводу можна сперечатися й додавати в скарбничку нові реалізації.

Із знайдених реалізацій алгоритму P. Gehrig знайшлася сторінка з прикладом: www.softtime.ru/javascript/snow-falling.html. По ній зрозуміло, про що йде мова. Невелика кількість сніжинок (15-20) і зараз не сильно грузить процесори (10-20% для не слабких ноутов), працює в Хромі і Firefox, хоча у списку підтримки читається Opera 9, IE5 і 6 і якийсь ранній Firefox. Зрозуміло, про Canvas тоді не знали.

Зведемо побачене в таблицю, де покажемо:
*) кількість частинок;
*) тип анімації;
*) наявність пісочниці для експериментів;
*) завантаження процесора (MacBook, Firefox 43) (Хром зазвичай % на 10 ефективніше);
*) коментарі про особливості.

(Реальні дані завантаження процесора будуть відрізнятися для різних комп'ютерів, для комп'ютерів з різними відеокартами і для мобільних пристроїв в широких межах. Дані для орієнтування для середньої потужності ноутбука з вбудованою графікою.)

Подивимося швидше на скрипти з застосуванням Canvas.
чистий JS Демо: 400x400, Snowman with Falling Snow
Частинок на демо: 100
Тип: Canvas
Пісочниця — ТАК
Завантаження: 70%
Рядків коду: 106 +ProcessingJS (800K)
Малюється в середовищі ProcessingJS на 800К нестисненого коду, що створює мову типу «Рапіра». Сніговик малюється тим же кодом. Приклад — особливий. Показує, що з оболонками накрутити можна чого завгодно (для вирішення простих завдань складними способами), і навіть у цьому випадку Canvas не катастрофічно програє рішень на DOM.
Стаття (en) 2012 Код: Github Демо: на весь екран
Частинок на демо: 500
Тип: Canvas
Пісочниця? Немає
Завантаження: 100%
Рядків коду: 50 + 100 *.html +ThreeCanvasJS (72C)
72 До стислого неупакованого коду бібліотеки ThreeCanvas.js. 3D-сцена з обертанням її рухом миші. Тут заради плавного руху поставлений малий бітрейт, тому все красиво, але як фонове дія — не дуже слушно.
Рік: 2010 Код: JS Демо і опис: на весь екран
Частинок на демо: 60, крутяться в площині малюнка
Тип: Canvas
Пісочниця? Немає
Завантаження: 100%
Рядків коду: 160
Дуже часта анімація не дозволяє і тут оцінити достоїнства Canvas. Є обертання мальованих сніжинок навколо своєї осі повільне падіння з блуканнями. Але частина з них «ходить» по синусоидам, кручення в одній площині анітрохи не додає реалістичності, що, навпаки, відштовхує від сприйняття ефекту, створює, швидше, ефект настирливості. Код — навпаки, показує свою потужність та компактність. В сумі — відмінні зусилля спрямовані на досягнення трохи не тих ефектів, що для споживача — нічим не краще поїдають енергію движків на DOM.
 
  Подивимося на приклади скриптів, які працюють з DOM (шарами), без Canvas.

Рік: 2009 Демо: jSnow – jQuery Snow Effect на весь екран Код: JS (незжатий колишньої версії)
Частинок на демо: 25
Тип: DOM
Пісочниця? Немає
Завантаження: 70%
Рядків коду: 160 + jQuery
Варіанти у пісочницях скрипка некваліфікований робітник (скрізь використовуються символьні сніжинки):
У цього скрипта — характерний почерк рухів частинок (сильно в сторони). Якщо придивитися — це просто дуже великі синусоїди, воспринимающиеся як один великий вихор посередині вікна. Він дуже стриманий щодо витрачання ресурсів. Вихідний код версії 1.2 — загублений або завжди був обфусцирован пакером; розпаковані версії 1.1.mod2 (допрацьовані іншими авторами) — є в пісочниці Codepen, але не працюють з новими jQuery, тому що звертаються до скасованих $.browser. І в них видно сліди розпакування. Чудово виглядає в невисоких заголовках (приклад), коли синусоїди не встигають проглядеться. З десятків прикладів, якщо варто придивитися до парі з них (за виконання коду), то цей приклад — один з них. Тому за версію jSnow візьмемося грунтовно, запустивши в пісочниці.
Що цікаво, упакована версія автора, 1.1 або 1.2 працює помітно швидше — при тих же зовнішніх налаштуваннях навантажує процесор на 40%, 1.1.mod2 — на 55%. (Фиддл теж швидше працює в багатовіконному режимі.) Швидше за все, так позначаються зайві перевірки в циклі відтворення сніжинок (в модах додані «фічі»). Сам код не гранично оптимізований — пише инлайновые стилі, які можна задати правилами.

Далі стало цікавіше — у коді при тестованих налаштуваннях виявився ряд багів (і це не означає, що знайшлися все). Деякі правки в коді доведеться робити (прибрати несумісність з jQ 2+, обчислення початкового положення сніжинки, не давати їм заходити за лівий край вікна — в маках це призводить до «вспыхиванию» смуги прокрутки, і корисно те ж саме робити для нижньої межі), тому краще користуватися модифікованими сучасними версіями.

Версії-моди (2009-2010) додали пару насущних «фіч» — налаштування плавного вицвітання сніжинок внизу (fadeAway: 1) і можливість прокрутки з неперемещением поля сніжинок (followScroll: 1). Назви залишені оригінальними, якими назвали їх розробники.

Мета налагодження старого коду у тому, щоб потім алгоритм перенести на Полотно і порівняти швидкості. (Калік перемагати — честі замало.) У налаштуваннях я повторюю ті ж помилки, над якими критикував інших. Для розробника неважливо, що різнокольоровий сніг, що падає в 2D, не буває — головне є технічна можливість розфарбувати. А ще, не летять сніжинки, а грудки в реальності. Але 3/4 населення Землі цього не знає, так що нас чекає успіх… В наборі сніжинок використано більшість символів Unicode, схожих на сніжинки — набралося аж 8. Можна знайти ще стільки ж.

Отже, вийшов читається код, на 20 рядків коротше (90 рядків) і в упакованому вигляді на 30% менше (1.5), ніж кращі зразки модів, не втративши при цьому функцій і додаючи стоп-старт-кнопку. Цей проміжний варіант компактний, але працює, як і раніше, з вікном і абсолютно може задавати висоту (height: число) у параметрах. Це не дуже зручно, тим більше, що плагін не використовують контекстну колекцію взагалі, тому нормально себе почуває з викликом дивного вигляду $().jSnow(...), тобто без контексту. Вийшло досить просто, обмежимося тут посиланням на демо.

І ускладнимо завдання — почати працювати з контекстними колекціями jQuery. Збережемо це поведінка, коли немає контексту — вибираємо роботу з вікном, як і при контексті window $('body')) і додамо роботу з блоком-контейнером (наприклад, запускати за $('.contSnow').jSnow(...) ). Контейнер доведеться підготувати, для нього потрібний position:relative, щоб вставити блок з absolute добре себе почував. Блок, який на все вікно, теж почне поводитися по-іншому, буде покривати вікно, тому весь вміст сторінки потрібно підняти, якщо буде такий блок. (Можна і інакше, по-старому, але навіщо ускладнювати? Скоріше, будуть використовувати або перший скрипт, або другий.) Вийде приблизно так:

демо, (код репо). Це DOM, навантаження 30% на потік (15% — загальна) з бітрейтом 12.
Кілька впливає те, що картинки — великі і прозорі.


Справді, навіщо працювати тільки з одним контейнером, якщо jQuery може надати колекцію? Виходить щось такого типу, навантаження 30-50% для суми 70-120 частинок. Зупинку-запуск теж можна розділити по кнопках або зробити загальною.

При спробах застосувати написане відразу впадає в очі непрактичність запуску скрипта на колекції. Запустити — так, можна, навіть десятки инстансов скриптів, роздаючи кожному по трохи сніжинок. Але всім блокам колекції повідомляються однакові параметри, і це — непрактично, т. к. частіше хочеться зробити іншу завдання — запустити трохи вікон (віртуальних, на дивах), але з різними параметрами, а для цього доводиться їх повідомляти одному елементу. Виходить, частіше всього, що скільки елементів, стільки потрібно запусків .jSnow, що виходить довго, хоча і наочно.

Тут виникає аналогія з написанням правил CSS. Правила — це ті ж декларації параметрів, які ми робимо при запусках плагінів, навіть селектори у плагінів стоять на своєму місці. Але немає зараз механизам поступово накопичувати опису правил (подібно до того, як в одному — font-size, в іншому — position). Другий запуск плагіна на тому ж елементі додає ще один інстанси плагіна (довгограючу функцію з замиканням і можливістю вимкнення), а не додає властивостей до вже запущеному. При цьому зручніше було б перераховувати селектори (просто рядки з класами), а не JSON-и налаштувань. Але не пригадується жодного плагіна, де такий спосіб конструювання налаштувань був би потрібен і працював. На самому просунутому варіанті демо напишемо запуск в 4 областях так, як плагін тепер вміє:


демо
, (кіт у репо)


Доопрацювання доданка додали близько 300 байт стисненого коду, але тепер він з великою підставою може називатися плагіном. Правда, без єдиного методу.

Інші скрипти для роботи з DOM
Таку увагу приділено одному скрипту, не самому просунутому, тому що, якщо зазирнути вперед, він виявляється невеликим конкурентом скриптам на Canvas, не тим, що вище, а добре, економічно написаним. Неефективно написані не стануть конкурентами, тому в коді не можна допустити нічого зайвого, щоб було з чим порівнювати.

Наприклад, є дуже популярний скрипт на DOM під назвою Snowstorm, зі стисненим кодом 20К, дуже великою кількістю налаштувань, відключенням в мобільних пристроях — є, чому повчитися і для малих скриптів. Але вивчати, що там зайвого і призводить це до втрат — дуже складне завдання. Простіше написати мале і розширювати налаштування. Значимість кожної з'ясується на тестах і практиці.

Швидко пройдемося по ще одному невеликому скрипту, який не знайдений серед гарно оформлених демо і пісочниць, але має цікаве поведінку (згадувався вище, автора P. Gehrig). Нема великих складнощів помістити його в пісочницю — доробок багів не вимагає, jQuery не використовує, але треба було привчити до сучасного доктайпу. Також, раніше було погано з особливими символами Unicode у системних шрифтів, зараз — краще, тому що падають літери замінені на падаючі текстоваые (подцвеченние) сніжинки.
Рік: 2005, falling-snow з налаштуваннями, код, jsFiddle
Частинок на демо: 25
Тип: DOM
Пісочниця? ТАК
Завантаження: 10% (з-за 8 СЕК)
Рядків коду: 90
Настільки мала завантаження системи у оригінальних налаштувань скрипта викликана низьким виставленим FPS. Це, звичайно, помітно по руху як часте слайдшоу. Це було потрібно для старих браузерів і попереджається в старих коментарях до скрипта. При 30 FPS — завантаження 35%, приблизно стільки ж, як у попереднього скрипта при таких налаштуваннях.

У цього скрипта є модифікація з додаванням броунівського руху і з падінням як би «здалеку» екрану, збільшенням і «таненням» (збільшенням прозорості) поблизу або внизу.
Рік: 2006, falling-snow з падінням «видали» з налаштуваннями, jsFiddle
Частинок на демо: 25
(дивитися в повному екрані)
Тип: DOM
Пісочниця? ТАК
Завантаження в jsFiddle: 60% (16 FPS)
Рядків коду: 100
Тут настройки розмірів досить «капризні» — невеликою зміною швидкості росту можна отримати величезні сніжинки або не ростуть, тому інші сценарії поведінки потрібно підбирати, а ефектність буде залежати в кінцевому підсумку від розмірів вікна і поведінки (не автонастраивается). Помітне підвищення навантаження пов'язане з отрисовной великих прозорих символів (зображень). (Вихідний код написаний щільно, реальна кількість коду після розрідження було б в 2 рази більше.)
Напишемо всі варіанти коду зі снігом на Гітхабі. Врахуємо недоробки попередників, які не писали демо-сторінок, і тому на їх код подивилися набагато менше людей. Гитхаб дозволяє дуже просто запускати демо, якщо працювати в гілці gh-pages. Тепер всі модифікації версій легко фіксуються в історії змін і виглядають відмінності. Гитхаб: github.com/spmbt/snowfalls.

Як там з CSS-анімаціями?
Дивимося приклади, написані іншими, далі, в пошуках ефективних алгоритмів і ефектних результатів.

1. Приклад (єдиний з анімаціями CSS) сильно загружающей анімації на CSS3 з обертанням DOM-сніжинок — www.jqueryscript.net/animation/jQuery-Plugin-For-Snowfall-Effect-with-Rotating-Snowflakes.html. (На цьому сайті є все — опис, код та демо для кожного сценарію, але без пісочниць.)

2. Анімація 3 картиночных шарах CSS (Codepen).

Пробуємо дивитися ще анімації на канвасі, щоб знайти не сильно нагружаюче систему скрипт.

Приклад анімації на Canvas, активирующейся по руху миші, де можна побачити, що прийнятне кількість сніжинок — не суцільна генерація з порядку 200-300, а близько 50-100 на екрані — www.jqueryscript.net/animation/Yet-Another-Falling-Snow-Animation-with-jQuery-Canvas-GlauserChristmas.html.

Ще одна анімація на Canvas без бібліотек, з демо і коментарями китайською: www.jqueryscript.net/animation/Nice-Snow-Falling-Effect-with-jQuery-Canvas-Nice-Snowing.html.

Всі ці анімації, включаючи Canvas, чомусь налаштовані так, що завантажують процесор на 100% (точніше, одне ядро, яке може завантажити однопотоковий JS). Це ніби вважається нормальним для демонстрацій скриптів. (Можливо, на дискретних відеокартах це так і є.)

якось це все дивно
Серед скриптів зі снігом зустрічається дуже мало заощаджують навантаження процесора, хоча вони є як для DOM, так і для Canvas. Покажемо, що того ж ефекту повного завантаження можна домогтися не 100, а для пари тисяч сніжинок, а нормальної краще вважати завантаження ядра на 10-20% для 200-400 штук.

Вибираємо ефективний Canvas
Втім, тут знайшовся один економічний скрипт на чистому Canvas. Свої приклади будемо робити приблизно в його стилі.
Рік: 2015 Демо: Snow Effect using HTML5 Canvas and Javascript на весь екран Копія jsFiddle
Частинок на демо: 25
Тип: Canvas
Пісочниця — ТАК
Завантаження: 45%
Рядків коду: 90
Приклад показує, що якщо ми контролюємо весь код, який не робить нічого зайвого, як це відбувається в прикладах вище, то успіх близький. Навантаження навіть з 200 частинками (в Хромі) становить 45% (потрібно дивитися 2 або 3 процесу — Chrome і два Chrome helper) і 60% при 2000. Для Firefox — приблизно те ж, хіба що на 10% повільніше (при хороших умовах) і більше випадкових гальмуючих факторів.
Але проблемен Canvas при малих навантаженнях. Навантаження при 2 частинках часто становить 40-60% і стільки ж — для 25, і 0 — для незапущенного setInterval(). Будь-яка його дорисовка навантажує процесор (при 30 FPS — відсотків 30), а обсяг домальовування не має великого значення. Очевидно, що при гіршій відеокарті результати будуть гірше, і де-то ми перестанемо бачити поліпшення, почне гальмувати завжди при наявності Canvas, а поправити можна буде тільки зменшенням FPS.

Більш детально, результати такі. Беремо jsFiddle як менш впливає на результати, копіюємо туди приклад з додаванням кнопки зупинки. Запускаємо різну кількість сніжинок, чекаємо приблизно хвилину, поки витрати процесора заспокоюються (не рухаючи мишу, нічого не роблячи). Дивимося результати через Activity Monitor (MacBook з відео Intel HD Graphics 5000). Якщо дивитися на Windows, скажімо, на 4-ядерному процесорі, то побачимо завантаження не більше 25%. Звані тут в статті 100% ставляться до завантаження одного ядра, тобто 25% треба буде помножити на 4. Просто браузери поки що по-іншому не вміють розпаралелюватися, але і це навантаження для ноутбука досить чутлива, призводить до витрати енергії, приблизно як при перегляді відео.

Не запущена відтворення -10% навантаження (фон).
0 частинок — 30%;
2 частиы — 35%;
25 частинок — 40%;
200 часток — 50%;
1000 — 55%;
2000 — 65%.
При цьому не завжди показання повторюються, залежить від інших запущених програм і зайнятості пам'яті.

Ось і розгадка того, чому з появою Canvas все відразу не кинулися програмувати на ньому. Процесори, початкове можливе недосконалість реалізації та неповна підтримка в браузерах не дозволяли робити прийнятний бітрейт, щоб з гарною якістю руху пройти «ценз продуктивності», залежить не від числа частинок, а від бітрейту, і вкластися при цьому в ідеалі в 20%. З анімацією на шарах можна запустити хоча б 5 частинок і пройти цей ценз. Зараз з продуктивністю стало краще, а IE8, який без Canvas, займає частку близько 0.5 відсотка.

Свої алгоритми на канвасі
Створимо свої варіанти економічних алгоритмів на канвасі. Спочатку замкнемо площину в тор і пустимо сніжинки по вітру з невеликими випадковими блуканнями, які застосовуються до швидкості кожної частинки. Виходить досить природно, хоча без враження про поривах вітру. Другий ефект паралакса, коли більш дрібні частинки падають повільніше, що створює відчуття тривимірності сцени.

З такими установками пішов перший млинець.
Рік: 2015 Демо і пісочниця: вітер з падінням і випадковими блуканнями швидкості, весь екран, загорнутий в тор
Частинок на демо: 100
Тип: Canvas
Пісочниця — ТАК
Завантаження: 35%
Рядків коду: 50
Випадковість блукань призводить до того, що деякі частинки досить велика їх кількість, летять, поступово змінюючи напрямок і літають все більш довільно. Потрібно «загасання» відхилень швидкості, щоб рій частинок приводився до загального потоку. Множник *.999 в коді створює це «заспокоєння». Але діє на швидкість взагалі, тому з часом вони будуть сповільнюватися. Для нескінченного падіння це не підходить, але треба падіння в межах екрану.

Наступний крок — це створення землі. Сніг буде на ній зупинятися і танути, щоб, розтанувши, частинки знову з'являлися зверху (для простоти буде поки що однакове число частинок, без оптимізацій).
Демо 2 і пісочниця: Сцена з таненням снігу внизу вікна на весь екран
Частинок на демо: 1000
Тип: Canvas
Пісочниця — ТАК
Завантаження: 40-50% (30 FPS)
Рядків коду: 50
Величина частинок впливає на те, де вони будуть зупинятися: чим більша частка, тим ближче до низу вікна. Це теж створює ефект тривимірності і випадкове заповнення «землі» сніжинками.

Спочатку потрібно запустити заряд снігу потужніше, щоб швидко утворився покрив. Через хвилину він на очах почне танути, а повністю станули частицв знизу переходять наверх. Кругообіг води.

Для початку рівноважного процесу, звичайно, потрібно рівномірно поставляти сніг з небес. Але і сезони і танення снігових зарядів мають свій шарм і нескучность. З цього демо негайно отримуємо картинку з оленями, посилання на яку була вгорі статті (код в пісочниці, 30% завантаження, 120 частинок).


Скрипти Kafeman в рамках хакатона
Паралельно скрипти зі снігом та іншими святковими ефектами робив kafeman.
Початкова ідея — побудувати вітальну сторінку з ефектами для відвідувачів клубу АДМ. Все могло бути серйозніше, але історія не терпить умовного способу. Крім чисто декоративного оформлення, відвідала ідея подивитися на реальний снігопад (1, 2, 3) і змоделювати ті неприємні близько мелькають частинки снігу. Досконалість ще не досягнуто, але напрям має всі підстави, інакше не згадається лепящийся на обличчя відволікаючий сніг. Тут треба поекспериментувати з промальовкою безформних пластівців і їх змазаним мигтінням.

І треба якось відрощувати сніговий покрив: jsfiddle.net/162e4jte/3, але не так, щоб він поглинув всю планету з космонавтом на ній. Спочатку він теж лягав горбиками і танув: jsfiddle.net/162e4jte/1. Така поведінка зустрічалося в скриптах інших авторів.

Накоец, на майбутнє ідея об'єднання генераторів движків в один теж заслуговує виконання. За результатами, крім маси скриптів сторонніх авторів, маємо 3-4 алгоритму руху частинок і 2 способи реалізації, загальні частини яких досить добре по представленим пісочницях і репо відстежуються.

Трохи статистики. У зв'язку з глобальним потеплінням інтерес до снігу в сукупності з Javascript? як і до лиж — падає, а інтерес до Canvas і Javascript — зростає. Тепер ми знаємо, в якій комбінації буде забезпечено стабільний інтерес.

Висновок
2 реально здійсненних для ефекту снігу способу програмування — DOM-шари і Canvas — мають свої ніші застосування. До приблизно 50 частинок виграє DOM, але не у всіх режимах, для завдань, де потрібна невелика навантаження на процесор. Високий бітрейт знижує планку. Більше 50 (але впевнено — більше 200) — але теж бажано з низьким бітрейтом — виграє Canvas. Але розщедрюватися треба на завантаження побільше — від 30% ресурсів процесора. Межа та критерії — дуже хистка і залежить від апаратури, браузера, успіхів реалізацій движка в браузерах. Мобільний користувач скаже категоричне «ні» більше 5 часткам, а стационарник з великою відеокартою щиро не буде розуміти, в чому проблеми з 200 частками в DOM і з 5000 в Canvas.

Все зайве з алгоритму для типового комерційного застосування (увага користувача в районі свят) потрібно прибирати, тестувати алгоритми на різних пристроях і приймати рішення про ніші покриття користувачів. Можуть бути більш виграшна низкобитрейтная ілюмінація на Canvas або короткочасні феєрверки на ньому. Не завадить підказати, якою кнопкою вимкнути анімацію і запам'ятати у налаштуваннях юзера, що «акція відпрацювала». Оскільки сніг не такий грошовий, як Яндекс-браузер, немає підстав «ламати» цю кнопку свідомо. Ще через пару років можна сподіватися, що становище з канвасом покращиться, і він повільно буде відбирати собі область малої кількості частинок і підвищеного бітрейта.

Виразні можливості скриптів снігу, в основному, на даному етапі вичерпані (нічого якісно нового не з'явилося в останні роки у цій групі). У досить завершених скриптів є ряд властивостей, визнаних необхідними, а частина нездійсненних по продуктивності властивостей (обертання сніжинок у форматі 3D) не виконується, але нікого це не бентежить. Але через продуктивної відтворення на канвасі можна очікувати, що такі скрипти з'являться (з навантаженням від 30%).

Перспективи кодування — можна написати конструктори, які давали б об'єкт для DOM або Canvas налаштуванням. Конструктори могли б писати різні автори. З таким підходом організований проект на ХабраАДМе (Гитхаб): github.com/clubadm/snowmachine.

Як ви ставитеся до появи на сторінках сайтів анімацій у вигляді падаючого снігу?

/>
/>


<input type=«checkbox» id=«vv70603»
class=«checkbox js-field-data»
name=«variant[]»
value=«70603» />
Завжди негативно, якщо немає альтернативи не дивитися таку сторінку
<input type=«checkbox» id=«vv70605»
class=«checkbox js-field-data»
name=«variant[]»
value=«70605» />
Частіше негативно, але при ненав'язливості ефектів — нейтрально або позитивно
<input type=«checkbox» id=«vv70607»
class=«checkbox js-field-data»
name=«variant[]»
value=«70607» />
Нейтрально, не помічаю таких ефектів анімації
<input type=«checkbox» id=«vv70609»
class=«checkbox js-field-data»
name=«variant[]»
value=«70609» />
Частіше позитивно, але іноді є бажання вимкнути
<input type=«checkbox» id=«vv70611»
class=«checkbox js-field-data»
name=«variant[]»
value=«70611» />
Завжди позитивно, практично немає випадків надмірної анімації

Проголосувало 73 людини. Утрималося 13 осіб.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.