Настольная игра AJAX отлично работает в Windows, но не в Linux

Question

Я недавно играл в настольную игру под названием Empires на GamesByEmail.com . Он работает нормально под Windows, но необычно медленно на Linux.

Я спросил разработчика, почему. Он использует Linux, но он не знает. Он подозревает, что в DOM слишком много элементов, но не знает, что делать с решением проблемы.

Это медленно и в Firefox, и в Google Chrome, поэтому, похоже, это не проблема браузера.

Я тестировал свой собственный сайт с Firebug и расширением Page Speed, поэтому я решил попробовать его на GamesByEmail. Результаты на ShowSlow . На самом деле он довольно быстрый с точки зрения обычной веб-разработки - он просто не работает в Linux.

Пожалуйста, можете ли вы все опытные разработчики Linux проверить игру и дать нам несколько подсказок?

http://gamesbyemail.com/Games/Play?475162291

Answer 1

Я парень, который написал «ужасный дизайн» под названием «Империи»: O

Изначально я знал, что это будет много логики, но я понятия не имел, во что ввязался.
В конце концов, зная, что существуют проблемы с производительностью (особенно на Mac и Linux), я решил, что лучше всего сделать его пригодным для игры, исправить его как можно лучше и получить его, чтобы я и некоторые друзья может играть в игру.

Оказывается, игра приближается к эпохе 7, производительность становится довольно плохой. (так много фигур на доске). Иан, еще раньше, когда я упомянул о слишком большом количестве элементов DOM, я ссылался на множество изображений.

Главный разработчик gamesbyemail.com (который делает потрясающие игры и не позволяет Empires обманывать вас по поводу качества своих игр!), Он упомянул, что разница в производительности между маленьким GIF и доской очень мала. размер GIF, который в основном прозрачный.

Проблема в том, что попытка клонировать HoTW-2001 привела к использованию большого количества изображений.

Есть несколько оптимизаций, которые я собирался пройти здесь, но у меня не было времени, чтобы завершить работу. (У меня уйдет около 12 часов или около того, чтобы протестировать все перед выпуском, и даже в этом случае ошибки легко пройти: (
Но у меня есть планы:

• Устранить все pngs (если я еще не ... там есть переменная, которая переключается между gifs или pngs. Мне так нравится прозрачность pngs, но этот дополнительный канал удваивает размер изображения: (
• Отключить импульсный эффект.
  Я хотел, чтобы это помогло определить «текущую империю», а не «предыдущие империи», принадлежащие одному и тому же игроку. Проблема в том, что для большинства браузеров анимация слишком дорогая :( (Я знаю, мне, вероятно, следовало бы использовать flash или тег canvas, но API Скотта настолько заманчиво богат и надежен ... слишком много, чтобы реализовать его самостоятельно).

Так что ... Мне просто нужно снять свою задницу и надеть на нее хотя бы предметы, перечисленные выше.

Трой

PS - Еще одним URL-адресом, который можно использовать для тестирования игры, может быть превью игры здесь . Вы можете сыграть всю игру как все игроки.

Answer 2

Еще одна идея.

Оригинальный API больше подходит для игр, которые используют плоские территории (например, Gambit и Вторая мировая война). Таким образом, вместо того, чтобы генерировать тысячи gif-файлов, которые содержат пятнистую штриховку (увеличивает изображение), я либо:

• Вернитесь к pngs, используйте один цвет, например: синий, но с прозрачностью 30%, и позвольте основной плате обеспечить заливку и текстуру. OR
• Используйте gif-файлы, один плоский цвет, без затенения и используйте свойства DOM, чтобы отобразить его полупрозрачным (в некоторых местах это уже делается с использованием нескольких различных свойств dom, специфичных для браузера). Единственная задача - сделать так, чтобы он выглядел хорошо.

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

Наконец, есть возможность объединить этот подход с подходом спрайтов, и вместо рендеринга тысяч отдельных изображений с мастер-карты (gimp image) я рендерирую территории в одно гигантское изображение (с дополнительным прозрачным пространством вокруг каждого территория).

Итак, некоторые идеи, которые я могу реализовать ... э-э, как только у меня открывается расписание:)

Трой

Answer 3

просто некоторые дополнительные отзывы: игра кажется невероятно медленной в Mac OS X Firefox тоже - пришлось перезапустить «лису» после того, как она замерзла ...! Ой!

Answer 4

Google Page Speed ​​проверяет, насколько хорошо сайт руководствуется лучшими практиками, а не тем, насколько эффективно он работает. Если в Chrome сайт работает вяло, попробуйте Google Speed ​​Tracer , который сообщит, что браузер делает на сайте. Сравните его вывод между windows и linux.

Answer 5

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

Function        Calls   Percent Own 
                                Time(ms) Time(ms)        File
mouseEvent()    658     4.69%   75.67   1596.14 GamesByEmail.js (line 4150)
onmousemove     576     1.07%   17.32   1575.29 26 (line 1)
mouseMove()     576     1.18%   19.04   933.05  Game.js (line 2122)
findAtPoint()   576     4.14%   66.9    594.48  EmpiresT...ritory.js (line 415)
containsPoint() 16217   6.00%   96.91   518.51  GamesByEmail.js (line 5676)
normal()        16217   14.65%  236.61  421.59  Foundati...ometry.js (line 485)
cancelScroll()  658     21.51%  347.38  347.38  GamesByEmail.js (line 4109)
mouseMoveHidePrevious()
                576     0.18%   2.94    266.65  Game.js (line 2153)
updateMouseHtml()61     0.16%   2.64    256.51  Game.js (line 2178)
updateMouseHtmlPosition()
                639     11.69%  188.87  216.47  GamesByEmail.js (line 3783)
setMouseHtml()  61      0.53%   8.58    206.75  GamesByEmail.js (line 3767)
containsPoint() 16217   5.78%   93.41   144.65  Foundati...ometry.js (line 312)
setInnerHtml()  61      1.99%   32.19   116.9   GamesByEmail.js (line 2578)
toString()      183     6.40%   103.33  103.33  Foundation.js (line 476)
washHtml()      61      0.10%   1.54    84.71   GamesByEmail.js (line 2566)
insertStyleForElements()
                122     0.40%   6.49    83.17   GamesByEmail.js (line 280)
mousePoint()    578     2.57%   41.53   67.59   GamesByEmail.js (line 4119)
containsXY()    16217   3.17%   51.24   51.24   Foundati...ometry.js (line 308)
getElement()    1008    1.98%   31.98   41.18   Foundation.js (line 507)
normal          16411   2.50%   40.34   40.34   Foundati...ometry.js (line 487)
Point()         1155    1.88%   30.34   36.38   Foundati...ometry.js (line 15)
canAttack()     614     0.30%   4.79    35.41   Empire.js (line 477)
... 

То, что я вижу, показывает, что все время съедено внутри mouseMove и его subfns. Определение, над какой территорией находится мышь, обычно является задачей O (n). Итерация по каждому полигону каждой территории, пока мы не найдем тот, который содержит мышь X, Y. (такие вещи, как «normal ()» являются частью этого процесса. Он также использует ограничивающие рамки, поэтому некоторая оптимизация там).

Но я не понимаю, как эта производительность может стать намного хуже в конце игры (с большим количеством наложений территории) по сравнению с началом игры с очень небольшим количеством наложений территории. Поиск по территориям, чтобы определить, в какой из них находится мышь, сам по себе может и не быть проблемой ... но некоторый побочный эффект, возникающий при этом, ИЛИ, что браузеры в Linux и Mac перегружены объемом элементов DOM созданный таким количеством крошечных изображений на экране (?)

Оценка изображений на экране:

• возможно 120 изображений для цветных территорий
• еще 130 или около того для выделенных территорий
• «куски.гиф», созданные для показа памятников, городов и парней армии, еще 240+ из них

Это только около 500 изображений на экране одновременно, или 250 изображений и 1 изображение в 240 раз

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

Может быть, мне нужно просмотреть весь код внутри территории.updateHtml (); (кто сказал, что это не кодовый вопрос? ... ха! Не думаю, что он видел 15000 строк JavaScript-спагетти-безумия, которое я написал: o).

Может быть, мне следует запустить аналогичный профиль, запущенный в эпоху 1, чтобы посмотреть, как это выглядит? Я отправлю, если узнаю больше.

Трой

Answer 6

редактировать:

Хорошо, это ужасный дизайн. Он загружает тонны картинок (по 2 на каждую область) размером с игровое поле (947x622) и накладывает их. Затем при наведении мыши на него переключает два. В любом случае, это причина плохой работы, я ожидаю.

Это помогло? Теперь, когда вы знаете, как это плохо реализовано, какое это имеет значение на самом деле? Просто играйте на Windows.

оригинальный пост Хорошо, говорить что-то быстро в Windows и медленно в Linux ничего не значит. Вы можете запустить его на четырехъядерном ядре 8 ГБ с огромным диском для Windows и нетбуком для Linux. Это сделало бы это медленно. Так скажите нам ... каковы технические различия между двумя машинами. Я предполагаю, что машина linux имеет меньше памяти, и это приложение любит много памяти для Java и графики.

Answer 7

@ Hogan & @CasualCoder, в задних каналах обсуждается именно то, что вы упомянули: производительность снижается по мере продвижения игры из-за изображений большого размера, используемых для цветных наложений. В игре используются:

• 129 Выделение изображений (светится территория при наведении мыши)
• 92 Цветные оверлеи (показывает, какому игроку принадлежит территория)
• 129 тегов IMG для эффекта Pulse (повторяет 129 изображений hilite).

= 350 тегов IMG.

В начале игры 92 цветных оверлея - это пустые изображения размером 1x1 пиксель. На каждой территории выделяется 1 изображение, в основном прозрачное, соответствующего размеру доски, но обычно виден только 1.

По ходу игры наложенные изображения заменяются изображениями, которые показывают одну территорию красным или синим цветом и т. Д., В зависимости от того, кому принадлежит игрок. Эти цветные накладки имеют тот же размер, что и доска, но в основном прозрачные. В то время, когда мы предполагали, что эти изображения будут рендериться так же быстро, как мелкие обрезанные изображения (и это, похоже, имело место в некоторых старых браузерах IE в Windows).

Но, основываясь на какой-то другой обратной связи с результатами теста, которую я получил, кажется, есть большая поддержка, что эти оверлеи размером 947x622 являются проблемой; в сочетании с тем, какие выделенные изображения также видны.

Это наихудший случай до 92 видимых IMG для завоеванных территорий, плюс, может быть, дюжина или около того IMGs пульсируют для текущей империи = 105 947x622 (размер платы) сложенных изображений. Проблема заключается в том, что это вызывает сильное замедление при перемещении мыши в браузерах Linux и Mac.

Я отредактировал свои gimp-сценарии, чтобы вместо этого генерировать блики и наложения максимально плотно обрезанными, и выводить данные смещения X и Y в текстовый файл (который я затем вставил в код и использовал для размещения новых изображений относительно верхних левый угол доски).

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

Еще раз спасибо за отзывы, ребята, я надеюсь, что новая обрезанная графика решит проблему.

Трой

Редактировать: Последний код обрезанных изображений для Empires теперь онлайн. Просто жду более общих отзывов, но пока кажется, что в Windows FF и Ubuntu FF он чувствуется гораздо более отзывчивым! Еще раз спасибо за помощь всем:)