Flash или Canvas?

Друзья, нуждаюсь в вашем совете. Продолжительное время пишу пошаговую стратегию, и так исторически сложилось, что клиент написан на HTML + JS/jQuery. Всё бы отлично, но народ требует делает большие карты, а тут и начинаются дикие тормоза. 20000 DIV-ов и это только тайлы почти без войск, а уже DOM получается нешуточный. Тормозит даже скрол, не говоря уже о анимациях и расчетах возможных путей.

Хочется это всё аккуратно перенести на более быструю технологию, но куда? Flash, Canvas? Ни с тем, ни с тем не работал, всё нужно курить с нуля. Какие плюсы и минусы этих технологий и самые важные вопросы:
1. Где будет быстрее?
2. Что предпочтительнее, если в будущем будет интеграция в социалки и планшеты?
3. Если канвас — какой фреймворк посоветуете под такую стратегию?

Сразу сильно благодарен.
  • Вопрос задан
  • 5387 просмотров
Пригласить эксперта
Ответы на вопрос 14
20 000 дивов — это проблемы с архитектурой, а не неправильный выбор технологии. Даже если Вы перейдёте на flash или canvas, то это не избавит от проблемы отображать такой массив данных. Вам нужно уменьшить количество отображаемых на клиенте данных.
Ответ написан
Graid
@Graid
Как пользователь говорю, делайте на Canvas, не нужен нам это ваш flash!
Ответ написан
@Emin
Flash

0. Как уже сказали выше, в лоб проблему не решить. Т.е. просто за счёт производительности не вылезти.
1. Проще разрабатывать. Как минимум некоторые вещи можно сделать через анимацию. Как максимум классический ООП. Это позволит проще работать с большим количеством объектов.
2. Подавляющее большинство игр в социалках — это флэш, что как бы намекает.
3. Про мобильные устройства. Гораздо проще будет портировать игру на AIR и распространять как приложение, чем возиться с мобильными браузерами.
Ответ написан
Комментировать
nazarpc
@nazarpc
Open Source enthusiast
Canvas — всё же работать будет в любом современном браузере, даже в мобильном, даже в устройствах от Apple.
Ответ написан
Комментировать
devolonter
@devolonter
По своему опыту могу сказать, что Flash будет работать быстрее, по крайней мере пока. Но скорость работы canvas постепенно улучшается. Например, в Хроме уже очень шустро работает.

Также можно очень выиграть в производительности canas, используя WebGL там где это возможно. Вот интересная библиотека, которая реализует 2d API через 3d — WebGL2D
Ответ написан
Комментировать
maeln0r
@maeln0r
Комменты сверху — проблема в логике постоения дом дерева говорят… Это вообщем то не так. Все давально таки грамотно сделано, вы молодец.

А к ответу на вопрос я бы на вашем месте выбрал flash, если не планируете делать приложение под iphone. Для apple продукции html5 и canvas. И попробуйте посмотреть на такое средство разработки как Construct 2 — это визуальная среда разработки для html5 логику, конечно, писать не совсем удобно, зато хорошее графическое представление.
Ответ написан
Комментировать
shpaker
@shpaker
Вольный хлебопашец
Canvas конечно же.
Ответ написан
Комментировать
dshster
@dshster
Javascript, Frontend
Не смотрел ссылки, но есть предположение не выводить в DOM полностью всю карту, а выводить только видимую область, а это явно будет меньше 20к элементов. В пример можно привести те же яндекс.карты первой версии, там фрагменты подзагружаются при попадании в поле видимости и удаляется при пропадании из видимости.
Конечно это условно и область видимости может быть шире реального размера видимого поля, но смысл не в выборе платформы, а в архитектуре, как писали выше. Ну и html5 будет проще переводить в мобильные платформы
Ответ написан
Комментировать
Aler
@Aler
А можно на Unity3d и скомпилировать во Flash. Получится флеш с аппаратным ускорением, а 4000 треугольников и 20-30 материалов (или сколько у вас типов тайлов?) провернет даже древний компьютер
Ответ написан
taliban
@taliban
php программист
Еще стоит отказаться от jQuery и использовать такую штуку, если хотите кардинально увеличить скорость работы с DOM
Ответ написан
@Eddy_Em
webGL
Ответ написан
Комментировать
SerDIDG
@SerDIDG
Не обязательно на что-то переходит, вам стоит просто разбить карту на участки, и нужные участки вставлять, а не видимые удалять.
Ответ написан
Комментировать
Wott
@Wott
я как-то писал похожую ( ну относительно — там карта была статичной, а отдельными обьектами были только «юниты» ) так что могу посоветовать как-то закешировать карту, что бы относительно статичная большая поверхность была таковой и для браузера. Можно агрегировать гексы в большие квадраты или гексы на сервере и сделать тайлы как на гугл-мапсах. И да, фильтровать обьекты на клиенте по viewport, иначе пользователи или большая карта опять забьет ресурсы клиента. Клиентский кэш можно подсмотреть в гуглмапсах, хотя там вроде ничего сложного.
Понятно что придется события мышки привязывать как-то через координаты, а спецэффекты делать еще одним слоем. Печально, но каждый элемент в виде дива удобен, но не жизнеспособен.

Можно сделать как это делается во флеше — принимать сырые данные по всем обьекстам и рисовать их на клиенте, но флеш это имхо старый век. Можно рисовать полную карту на canvas, но для действительно больших карт имхо лучше это сделать через тайлы в четверть-восьмушку viewport
Ответ написан
Комментировать
StrangeAttractor
@StrangeAttractor
Если бы у меня был выбор, то я скорее всего выбрал бы Flash как систему, изначально созданную именно для таких задач (всё же когда речь заходит о создании полноценных ("rich") приложений, я питаю некую антипатию к HTML и сопутствующим технологиям, настоящая задача которых - вёрстка текстовых документов).

Но выбора уже давно нет, Flash уже закопан по пояс, если не по шею в землю - так решили сильные игроки рынка, включая саму Adobe. Так что при "выборе" между стандартными HTML-технологиями и Flash ответ - однозначно первое, если только перед Вами не стоит задача по-быстрому написать приложение, которое будет работать только под x86 Windows и будет актуально в течение ограниченного времени.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы