Flash или Canvas?

Question

[svoyak]

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

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

Сразу сильно благодарен.

Answer 1

[Виталий Желтяков]

20 000 дивов — это проблемы с архитектурой, а не неправильный выбор технологии. Даже если Вы перейдёте на flash или canvas, то это не избавит от проблемы отображать такой массив данных. Вам нужно уменьшить количество отображаемых на клиенте данных.

Comments

[gooddy]

Вот именно, что с таким подходом завернётся всё что угодно. Надо сделать какой-то механизм повторного использования DOM-елеметнов, которые вышли за область видимости. и в реальности их будет не больше чем помещается на экране.

[Emin]

Вам нужно посмотреть в сторону шаблонов «Пул объектов» и «Приспособленец»:

[Emin]

Отправилось раньше времени:
ru.wikipedia.org/wiki/Объектный_пул
ru.wikipedia.org/wiki/Flyweight

Answer 2

[Graid]

Как пользователь говорю, делайте на Canvas, не нужен нам это ваш flash!

Comments

[svoyak]

Если Canvas — это только iframe приложение в социалках. А iframe, если мне не изменяет память, с другого домена не развернешь на весь экран, только поэтому я сомневаюсь в выборе.

Answer 3

[Emin]

Flash

0. Как уже сказали выше, в лоб проблему не решить. Т.е. просто за счёт производительности не вылезти.
1. Проще разрабатывать. Как минимум некоторые вещи можно сделать через анимацию. Как максимум классический ООП. Это позволит проще работать с большим количеством объектов.
2. Подавляющее большинство игр в социалках — это флэш, что как бы намекает.
3. Про мобильные устройства. Гораздо проще будет портировать игру на AIR и распространять как приложение, чем возиться с мобильными браузерами.

Answer 4

[Назар Мокринский]

Canvas — всё же работать будет в любом современном браузере, даже в мобильном, даже в устройствах от Apple.

Answer 5

[devolonter]

По своему опыту могу сказать, что Flash будет работать быстрее, по крайней мере пока. Но скорость работы canvas постепенно улучшается. Например, в Хроме уже очень шустро работает.

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

Answer 6

[maeln0r]

Комменты сверху — проблема в логике постоения дом дерева говорят… Это вообщем то не так. Все давально таки грамотно сделано, вы молодец.

А к ответу на вопрос я бы на вашем месте выбрал flash, если не планируете делать приложение под iphone. Для apple продукции html5 и canvas. И попробуйте посмотреть на такое средство разработки как Construct 2 — это визуальная среда разработки для html5 логику, конечно, писать не совсем удобно, зато хорошее графическое представление.

Answer 7

[Aleksandr Shpak]

Canvas конечно же.

Answer 8

[Dmitry Shvalyov]

Не смотрел ссылки, но есть предположение не выводить в DOM полностью всю карту, а выводить только видимую область, а это явно будет меньше 20к элементов. В пример можно привести те же яндекс.карты первой версии, там фрагменты подзагружаются при попадании в поле видимости и удаляется при пропадании из видимости.
Конечно это условно и область видимости может быть шире реального размера видимого поля, но смысл не в выборе платформы, а в архитектуре, как писали выше. Ну и html5 будет проще переводить в мобильные платформы

Answer 9

[Aler]

А можно на Unity3d и скомпилировать во Flash. Получится флеш с аппаратным ускорением, а 4000 треугольников и 20-30 материалов (или сколько у вас типов тайлов?) провернет даже древний компьютер

Comments

[Aler]

если сделать на один тайл 4 треугольника (геометрией сделать шестиугольник), то можно избавиться от альфа-теста.

Answer 10

[Анатолий]

Еще стоит отказаться от jQuery и использовать такую штуку, если хотите кардинально увеличить скорость работы с DOM

Comments

[pxx]

Одно другое не исключает, в принципе. На счет альтернативы jQuery, посмотрите на ZeptoJs:
— полностью поддерживает синтаксис
— поддерживает большую часть функционала
— работает быстрее и весит значительно меньше, так как отказались от поддержки доисторических браузеров

[Анатолий]

Zepto вообще не обещают работу в ие, это не серьезно

Answer 11

[Eddy_Em]

webGL

Answer 12

[SerDIDG]

Не обязательно на что-то переходит, вам стоит просто разбить карту на участки, и нужные участки вставлять, а не видимые удалять.

Answer 13

[Wott]

я как-то писал похожую ( ну относительно — там карта была статичной, а отдельными обьектами были только «юниты» ) так что могу посоветовать как-то закешировать карту, что бы относительно статичная большая поверхность была таковой и для браузера. Можно агрегировать гексы в большие квадраты или гексы на сервере и сделать тайлы как на гугл-мапсах. И да, фильтровать обьекты на клиенте по viewport, иначе пользователи или большая карта опять забьет ресурсы клиента. Клиентский кэш можно подсмотреть в гуглмапсах, хотя там вроде ничего сложного.
Понятно что придется события мышки привязывать как-то через координаты, а спецэффекты делать еще одним слоем. Печально, но каждый элемент в виде дива удобен, но не жизнеспособен.

Можно сделать как это делается во флеше — принимать сырые данные по всем обьекстам и рисовать их на клиенте, но флеш это имхо старый век. Можно рисовать полную карту на canvas, но для действительно больших карт имхо лучше это сделать через тайлы в четверть-восьмушку viewport

Answer 14

[StrangeAttractor]

Если бы у меня был выбор, то я скорее всего выбрал бы Flash как систему, изначально созданную именно для таких задач (всё же когда речь заходит о создании полноценных ("rich") приложений, я питаю некую антипатию к HTML и сопутствующим технологиям, настоящая задача которых - вёрстка текстовых документов).

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