Flash и javascript: Javascript Flash мост

Flash vs JavaScript / Хабр

Здравствуйте, я разработчик игр на Flash. Последнее время все больше стало появляться постов про флешокапец, и MustHave JavaScript (дальше JS). Вроде как за JS будущие, и за открытым вебом.
Я долго не рассматривал JS всерьез как платформу для разработки игр. Ведь это интерпретированный язык, и скорость JS оставляет желать лучшего. Но совсем недавно был портирован на JS мой любимый фреймворк для анимации TweenLite. Вместе с этим автор создал тестовый пример показывающий производительность актуальных JS фреймворков: здесь.

Мне стало очень интересно, так как TweenLite JS выдавал неплохие FPS. И тут я решил написать такой же пример для сравнения Flash и JS фреймворков.
Дальше мне стало интересно сравнить FPS этих примеров в разных браузерах, и на разных ОС.
Сам тест — это анимация передвижения, и изменения размеров картинок, при чем можно изменять их количество. Тестовый пример для Flash лежит здесь, исходники примера здесь.

Тестирование проводилось на моем старом ноутбуке HP Compaq 625:
Железо:
AMD Turion II Dual-Core P520 (2.3 ГГц), RAM 2 ГБ, ATI Radeon HD 4200.

Операционные системы:
Windows 7 x32, Linux Mint 13 x32

Браузеры и Flash Player:
Google Chrome 21.0.1180 (Flash Player 11.3.31), FireFox 15.0.1 (Flash Player 11.4.402 for Windows, FP 11.2.202 for Linux), Interrnet Explorer 9.0.8112 (Flash Player 11.4.402)

Хочу сказать что Flash Player на Firefox-е был установлен разных версий под разные ОС, потому как официальная поддержка от Adobe на Linux уже закончилась, будут доступны только обновления безопасности для ветки 11.2. В отличии от Firefox, в Google Chrome Flash Player работает через новый межплатформенный API для плагинов Pepper API, и поэтому он обновляется до последней версии.

Итак, посмотрим, что получилось:

Тест №1:

Frames Per Second (Chrome 21.0. 1180, Flash Player 11.3.31, Windows 7 x32)
Frameworks\Tests	TweenLite (AS)	tweener (AS)	GTween (AS)	jQuery (JS)	TweenLite (JS)	YUI3 (JS)	MooTools (JS)	Dojo (JS)	TweenJS (JS)	Zepto (JS)
500	60	60	60	16	60	6	12	22	17	47
1000	60	41	60	1	51	1	5	5	2	28
3000	21	6	19	1	16	1	1	1	1	5

Здесь проводилось три теста, для 500, 1000 и 3000 тысяч картинок. Как видим большой отрыв Flash фреймворков и TweenLite JS, при 3000 картинок он обогнал даже флешовский tweener. Хорошо показал себя zepto, а вот всеми любимый jQuery для анимации подходит весьма плохо. Можно сделать вывод, что если такими темпами и дальше пойдет развитие то в JS есть все шансы стать достойной заменой Flash.

Дальше, мне стало интересно как колеблется производительность на разных браузерах и на разных операционных системах. Ведь flash player разрабатывается одной канторой, и сильных отклонений в производительности быть не должно. А движок JS пишется под каждый отдельный браузер, совершенно разными людьми (велоэффект). Поэтому давайте посмотрим на результат.

Как видим хотя flash player один и тот же, но ведет себя в разных браузерах по разному, это скорее из за того что использует разные API при взаимодействии с браузерами. Самым неудачным плагин FP получился для Internet Explorer.

Теперь рассмотрим тест на производительность браузерных движков JavaScript. Здесь тест проводился на 500 картинок, потому как при 3000-и многие фреймворки просто зависают.

Самым быстрым оказался Google Chrome, что не удивительно, смотря на то сколько денег инвестирует в него Google. Дальше Firefox возможно ситуация изменится при внедрении нового инкрементного сборщика мусора.И в конце Internet Explorer. Разрыв между первым и последним просто колоссальный. Представляете вы написали игру на JS, и она у вас хорошо работает в Chrome, Firefox, но тут кто то зашел из IE, можно представить что будет дальше, IE зависнет и скорее всего впадет а вместе с ним очень много открытых вкладок. Как результат юзер добавит ваш сайт в черный список. Была бы игра на flash такого бы не случилось.

Раз такой достаточно большой разброс производительности Flash Player на разных браузерах, давайте теперь посмотрим как она будет изменяться на разных ОС в одном и том же браузере:

Печальная картина, но видать в виду малого распространения Linux, Adobe халатно относятся к оптимизации их плеера на этой ОС. Результаты Firefox выкладывать не буду, потому как считаю нечестным сравнивать flash player 11.4 и 11.2, а на самом деле разница чутли не в два раза.

Идем дальше, как ведет себя JS движок на разных ОС?

Как видим Chrome идет практически одинаково что не может не радовать, а вот у Firefox, Linux версия заметно отстает.

Заключение:

Как видим производительность JavaScript растет, это радует. Но остается немало проблем:

• Нужно тестить как будет вести себя игра во всех браузерах, и надеяться что при выходе нового IE дай Бог ничего не отвалилось.
• Разница у производительности браузеров, будет давать неприятный эффект, на одних игра летает на других тормозит.
• Исходный код скрыть не удастся разве что сильно обфусцировать.

Какие еще проблемы ждут при разработке клиентской части игры на JavaScript и как их можно решить?

Flash vs Javascript. Размышления о Web-приложениях.

/ Хабр

Совсем недавно в разработке проекта перед моей командой встала задача реализации интернет приложения в котором один его компонент не должен перезагружаться при переходе с одной страницы на другую. Варианта нашлось 2 либо делать полностью Flash приложение, либо использовать внедрение методами iframe или object. Flash отпал ввиду технических требований портирования проекта на портативные устройства, посему остался JavaScript и object. В итоге мы остановились на схеме:

Контейнер и два вложенных в него объекта. Предварительное тестирование структура прошла и мы принялись за реализацию но

Глава 1. AJAX против браузерной системы навигации.

Пока разработчки браузеров не осознали что сайты уже давно перестали быть набором html страниц, и все больше и больше становятся похожи на приложения, перед нами (веб-разработчиками) стоит сложная задача о корректном функционировании кнопок вперед-назад при частичном обновлении контента.
Наща задача еще более осложнена тем, что фактически обновляемая страница (контент) вложена в контейнер и даже полном обновлении страницы контента, адресная строка не меняется. А это лишает пользователя привычным способом возможности получить прямую ссылку на контент внутри сайта. Под привычным способом я подразумеваю копирование адреса из адресной строки.

Когда список проблем был очерчен мы стали искать решения. И оно было найдено в window.location.hash. Я вспомнил что видел как на одном сайте его зачем-то меняли методами JS, но не придал этому значения. Позже когда я делал поиск на своем проекте я наконец-то понял, что в хэш можно просто писать ту самую часть ссылки, которая обычно идет за именем домена/. И именно так мы и сделали.
Решение проблемы с актуальной адресной строкой породило другую. Перестали работать кнопки «Вперед»-«Назад», потому как в единственное, что менялось в адресной строке — это hash. То есть фактически переход по history происходил, но браузер видя что URL не изменился не перегружал страницу контента. Пришлось вешать таймер, который раз в пол-секунды опрашивал адресную строку на предмет изменения и, если такое происходило, то перегружал контент. Путем шаманства и JS-кунг-фу было достигнута работоспособность во всех популярных браузерах.

Глава 2. IE опять опускает с небес на землю.

В процессе решения проблемы с навигацией, мы распрощались с XHTML-валидной вёрсткой. Потому как тег object, который мы так удачно заюзали вместо deprecated iframe напрочь отказался давать доступ к своему parent window. Потратив много времени на шаманство мы простились с валидатором и вставили iframe. Помимо этого IE дал прикурить и просраться на тему прозрачных PNG, вставки Flash и экспорта его методов в JS. Но это мелочи, которые известны многим и широко освещены в интернете, поэтому я не буду заострять ваше внимание на них.

Кстати, SWFObject не проходит валидацию.

Глава 3. А вот и Flash

Отказаться от использования Flash мы изначально не могли. Тогда бы у нас не было аудиопроигрывателя и многопоточного загрузчика. Но вместо того, чтобы делать визуальные элементы на Flash мы сделали тонкие модули без интерфейса выделив каждому жилплощадь в размере 1х1 пиксель. Если делать их бомжами, то они в знак протеста перестают экспортировать свои методы в JS. Мы приняли решение поместить все модули в контейнер и это позволило нам сделать фоновую загрузку. То есть можно поставить на закачку файлы и уйти со страницы загрузки, потом вернуться на нее, а файлы продолжают закачиваться. (Данный режим ещё не включён в официальный релиз, так как мы не уверены в его стабильности.) Ко всему прочему сделав тонкие модули мы минимизировали количество стыков JS<->Flash и тем самым повысили отказоустойчивость всей системы. Но тут Safari сказало свое решительное НЕТ. Дело в том, что по непонятным причинам JS не может дернуть Flash за его экспортированные методы, если они находятся в разных фреймах. К счастью после каникул у нас в офисе появится MacBook для производственных целей и поборем этот браузер.

Глава 4. Сегодня я многое понял.

Самое первое что выяснилось — это то, что нет идеального браузера, все «ломаются» когда начинаешь гонять на них по бездорожью на предельной скорости. Особо порадовал IE с PNG, Opera с тем что при изменении Opacity она упрямо накладывает ее на все внутренние элементы блока, из-за чего эффект растворения начинает тормозить, и конечно же FireFox, который при обработке JS «переключается как бабушка». Особо это касается анимации.

Вместо заключения.

Внимательный читатель спросит меня: «Какое отношение имеет заголовок к содержанию?».
Сейчас каникулы, и есть время подумать. Вот я сижу и думаю не было бы проще все-таки сделать сайт на Flash. Не смотря на все прелести, которые предоставляет HTML+JS.

Flash — MozillaWiki

• 1 Что?
• 2 Почему?
• 3 Как?
• 4 Кто?
• 5 Где?
• 6 Когда?
• 7 ссылок

Проигрыватель Adobe Flash Player обычно используется в Интернете для видео, анимации, игр, рекламных баннеров и «служебных» функций, недоступных в стандартном HTML+JS (таких как загрузчик файлов Gmail и кнопка буфера обмена GitHub).

Mozilla работает над рядом проектов по сокращению использования подключаемых модулей браузера, таких как Flash.

Плагины могут нести ответственность за ошибки безопасности и нестабильность, а также могут создавать неудобства для пользователей Firefox. Перенос этой функциональности на открытые стандарты может помочь решить эти проблемы на многих платформах.

• Снижение потребности в Flash-контенте за счет улучшения альтернатив веб-платформы:
  • ошибка 1083588 — Расширения источника мультимедиа (MSE) для видео YouTube HTML5
  • ошибка 1015800 — видео Encrypted Media Extensions (EME) для видео HTML5
  • ошибка 1121280 — Улучшение полноэкранного взаимодействия с пользователем для видео HTML5
  • RTMP.js, клиент JavaScript для протокола обмена сообщениями в реальном времени Adobe для потокового видео
  • asm.js, Emscripten и Unity для запуска игр на C++ в Интернете практически на исходной скорости без подключаемых модулей.
• Уменьшить количество экземпляров подключаемого модуля Flash:
  • Сделать плагины кликабельными
  • Shumway для Flash-видео, рекламы и игр
  • ошибка 1120676 — добавлен режим энергосбережения плагина для приостановки внеэкранного или неактивного Flash-контента
  • Когда-нибудь прекратите поддержку плагинов NPAPI. Google планирует прекратить поддержку NPAPI в Chrome в сентябре 2015 года.
• Уменьшение проблем со стабильностью, вызванных подключаемым модулем Flash:
  • ошибка 1116806 — Инициализация асинхронного подключаемого модуля: введение
  Ошибка
  • 1123755 — песочница Gecko NPAPI
  • Эксперимент по измерению последствий отключения защищенного режима Adobe

В этом участвуют многие люди. Вот контакты для различных областей проекта:

• Планирование
  • Бенджамин Смедберг
  • Шейла Муни
  • Крис Петерсон
• МСЭ/ЕМЕ
  • Энтони Джонс
  • Крис Пирс
• Полноэкранный UX
  • Джет Вильегас
• Шамуэй
  • Тилль Шнайдерайт
  • Майкл Бебенита
• Песочница
  • Боб Оуэн <боуэн>
  • Джед Дэвис
  • Брэд Лэсси <бласси>
• Эмскрипт/asm. js
  • Алон Закай <азакай>
  • Люк Вагнер <люк>
• RTMP.js
  • Юрий Делендик

• Заметки о собрании по обзору программы Flash

• Март 2014: Mozilla и Unity внедряют Unity Game Engine в WebGL
• Декабрь 2014 г.: Стартовое совещание по плану улучшения производительности флэш-памяти на мероприятии Mozilla All-Hands 2014 в Портленде
.
• Январь 2015 г.: План улучшения производительности Flash начинается

• Графики истории сбоев KaiRo Firefox
• Флэш-доска Trello
• Встреча с показателями YouTube
• Список рассылки метрик YouTube
• Flash/Hang_Debugging

CheerpX For Flash — запуск Flash-контента в браузере без Flash Player

Последний выпуск:

CheerpX для Flash — это решение для организаций, позволяющее поддерживать приложения Flash, работающие в современных браузерах (Chrome, Edge, Firefox) без использования подключаемого модуля Adobe Flash. CheerpX для Flash — это чистое решение HTML5/JavaScript/WebAssembly, которое добавляется к существующим немодифицированным приложениям Flash для преобразования их в страницы HTML5.

Это позволяет конечным пользователям получать доступ к существующему содержимому Flash с помощью стандартных браузеров и не требует каких-либо изменений исходного кода Flash для работы. CheerpX для Flash добавляется к существующим Flash-страницам либо с помощью одной строки JavaScript, либо с помощью расширения браузера (для динамически генерируемых Flash-страниц).

Ссылка на основной проект

Что такое CheerpX для Flash?

CheerpX для Flash состоит из трех компонентов:

1. Среда выполнения Adobe Flash. Коммерческая сборка среды выполнения Adobe Flash, предоставленная Harman (сопровождающая Flash), лежит в основе CheerpX для Flash. Срок действия этой специальной сборки не истечет, она не будет объявлена ​​устаревшей, и ее не нужно устанавливать конечному пользователю. Это внутренняя зависимость CheerpX для Flash.
2. CheerpX Среда выполнения Flash запускается «эмулятором» HTML5 на основе CheerpX в пользовательском браузере. Он выполняется полностью на стороне клиента, незаметно для пользователя. CheerpX — это технология на базе WebAssembly для безопасного запуска изолированных, немодифицированных двоичных файлов на стороне браузера как части приложений HTML5.
3. HTTP-хостинг Flash Player и CheerpX размещаются на HTTP-сервере, как правило, вместе с исходным статическим содержимым Flash и HTML. CheerpX для Flash интегрируется на любую страницу Flash HTML5 путем добавления на страницу однострочного скрипта, как и любые другие внешние библиотеки Javascript. Для динамически генерируемых Flash-страниц доступны альтернативные методы интеграции.

Почему мне следует использовать CheerpX для Flash?

1. CheerpX для Flash позволяет вам продолжать поддержку ваших внутренних, клиентских или общедоступных приложений после устаревания Flash без полной перезаписи HTML5.
2. CheerpX для Flash работает в современных браузерах, снижая риски, связанные с сохранением работы устаревшего браузера. Благодаря песочнице HTML5 он радикально повышает безопасность по сравнению с исходным проигрывателем Flash.
3. CheerpX для Flash можно использовать для внешних приложений B2B и B2C, поскольку пользователям не требуется загружать или устанавливать что-либо конкретное для запуска вашего приложения Flash.
4. CheerpX для Flash легко интегрируется и не требует внесения каких-либо изменений в исходное приложение.

Как работает CheerpX для Flash?

Проще говоря, вы можете разбить CheerpX для Flash на:

1. Среда выполнения Flash CheerpX для Flash запускает Adobe Flash Player и его среду выполнения в WebAssembly. Это означает 100% совместимость с Flash и требует лицензии на коммерческое распространение, обычно приобретаемой у Harman.
2. Новейшая технология на основе WebAssembly Основанная на нашей технологии виртуализации HTML5 CheerpX, она позволяет поддерживать существующие приложения Flash в современных браузерах после прекращения поддержки Flash.