Вибір технології для розробки переглядачів

Опис завдання

У зв'язку з ситуацією з підтримкою (а точніше її відсутністю) технології Flash на iOS, мене попросили перевірити можливість реалізації ігор з багатою графікою на «чистих» браузерних технологіях. Чесно кажучи, Flash далеко не сама моя улюблена платформа (так як є закритим продуктом Adobe, а не open source), що лише додало мені мотивації показати, що можливі хороші результати і без неї...

Однак, незважаючи на особисті переваги, Flash надає не тільки єдине середовище виконання (runtime), яке однаково здійснюється на багатьох платформах, але і багате середовище розробки, яке на сьогоднішній день цілком замінити неможливо.

В результаті огляд технологій виглядав як пошук компромісів між можливістю підтримки кінцевого продукту на масі платформ і зручності розробки ПЗ.

Список переглядачів, які ми повинні підтримувати:

  • Explorer 9+
  • Firefox 3.6+
  • Opera
  • Chrome
  • Safari
  • iOS MobileSafari
  • Переглядач Android WebKit

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

На сьогодні, на мою думку, немає адекватних альтернатив дизайнерському середовищу Flash, яке дозволяє скриптувати анімацію, містити об'єктну модель («Scene Graph»), а також вільно інтегруватися з Adobe Illustrator та іншими робочими інструментами для дизайнерів.

Як тільки ми йдемо з протоптаного шляху комерційного вендора, відповідальність за визначення методів переходу графіки від дизайнера до фронтенду програмісту лягає на нас.

Пошук починається

Спочатку SVG був протестований як графічна мова високого рівня. Він має такі плюси:

  • Відносно високий рівень абстракції - має свою об'єктну модель, яка дозволяє обробляти події.
  • Підтримує складні елементи анімації, такі як рух об'єкта по траєкторії, морфінг форм, декларативна анімація
  • всі прийоми векторного формату
  • об'єктна модель самого формату дещо замінює потребу в об'єктній моделі сцени - Scene Graph.
  • SVG - поширений формат, легко експортується та читається різними графічними програмами.

З таким списком переваг, можна було б подумати, що технологія просто ідеальна. Однак, при тестуванні проявилися такі недоліки:

  • Рівень реалізації та підтримки складного стандарту сильно відрізняється між браузерами і платформами
  • На деяких платформах реалізація вельми повільна.
  • Об'єктна модель SVG (DOM) надмірно складна і важка для роботи зі сценами, в яких необхідно динамічно додавати і видаляти об'єкти.

В результаті було вирішено спробувати підхід на більш низькому рівні, використовуючи Canvas з бібліотекою абстракції Processing.JS для полегшення роботи. Переваги:

  • Canvas є простим стандартом, і в результаті універсально підтримується на сучасних браузерах.
  • Processing надає додатковий рівень абстракції, що дає можливість, наприклад, імпортувати SVG.
  • Canvas дає попіксельний контроль над полотном.

Реалізація першої тестової сцени в Canvas/Processing показала, що багато базових функцій SVG відсутні, і їх довелося дописувати руками. Наприклад:

  • рух об "єкта за траєкторією
  • реакція об'єктів на дії миші
  • морфінг форм, будучи складним для імплементації алгоритмічно, був переведений на еквівалент спрайтової анімації, а сама покрокова анімація здійснена в редакторі Inkscape.

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

Були зроблені спроби оптимізувати демо (скасована покадрова перерисовка фону, зменшено кількість об'єктів на екрані, скасована текстура об'єктів). Але результат все одно залишався незадовільним.

Рішення

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

На цих пристроях швидка графіка здійсненна лише при використанні рідного графічного прискорення. А в MobileSafari це тільки об'єктна модель HTML (DOM).

Саме ця думка призвела до того, що демо Блек Джек столу було перероблено, на цей раз з використанням HTML і CSS3. Так само було додано звук і деякі ефекти прозорості... і - заробило! Відразу ж після переходу, фреймрейт на MobileSafari покращився.

Після додаткового читання і спеціалізованих оптимізацій, швидкість була піднята ще вище. Виявляється, в iOS 4.x MobileSafari лише частково прискорений, і треба обережно вибирати методику звернення до DOM щоб вичавити все можливе з цього браузера.

Особисто я був здивований можливістю реалізації браузерної гри з багатою графікою використовуючи всього лише CSS трансформації і HTML. Будучи охопленим пошуком «срібної кулі» у формі просунутої технології, я мало не упустив «хліб і сіль» веб програмування, поки не випробував і не відклав у бік всі інші можливості.

Я не хочу всім цим сказати, що Canvas і SVG не мають свого місця. Але з вищезгаданими цілями, SVG відпадає будучи більш придатним для статичних складних діаграм, а Canvas не тягне на Apple пристроях цього покоління. Залишається лише одне: CSS3.

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

Посилання на початковий код

Всі приклади коду в цьому тексті можна завантажити і подивитися з ГітХаб аккаунта письменника:

  • початковий SVG демо
  • початковий демо Canvas/Processing
  • демо БлекДжек столу, Processing (table.html) і CSS3 (table2.html)