Question

我最近在GamesByEmail.com玩了一个名为 Empires 的网络游戏。它在Windows下运行良好，但在Linux上速度非常慢。

我问开发商为什么。他使用Linux，但他不知道。他怀疑DOM元素太多，但他不知道如何解决这个问题。

在Firefox和谷歌浏览器中都很慢，所以它似乎不是浏览器问题。

我正在使用Firebug和Page Speed扩展程序测试我自己的网站，所以我想我会在GamesByEmail上尝试一下。 The results are up at ShowSlow。从传统的Web开发的角度来看，它实际上相当快 - 它只是在Linux上被打破了。

请所有熟练的Linux开发人员查看游戏并给我们一些线索吗？

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

Answer 1

我是那个写着“可怕的设计”的人，名叫“帝国”：O

最初我知道这会有很多逻辑，但我不知道自己会做些什么。
最后，知道存在性能问题（特别是在Mac和Linux上），我认为我最好至少让它可玩，尽可能地修补它并把它带到那里让我和一些朋友可以玩游戏。

随着游戏越来越接近Epoch 7，性能变得非常糟糕。（董事会上有这么多件）。 Iain，当我提到有太多的DOM元素时，它更早，这是我所指的许多图像。

Gamesbyemail.com背后的主要开发者（谁制作了精彩的游戏，并且不让帝国愚弄你的游戏质量！）他提到小GIF和棋盘之间的表现差别很小 - 尺寸gif，大多是透明的。

问题是尝试克隆HoTW-2001会导致使用大量图像。

我已经准备好了一些优化，但没有时间来完成。（在发布之前，我需要大约12个小时的时间来测试所有内容，即使这样，bug也很容易通过:(
但是，我确实有计划：

消除所有png（如果我还没有......那里有一个var在gifs或png之间切换。我非常喜欢pngs的透明度，但额外的通道使图像大小加倍：（
关闭脉冲效果我希望这能帮助识别“当前的帝国”而不是同一个玩家所拥有的“以前的帝国”。问题是，对于大多数浏览器来说，动画的价格实在太高了:( （我知道，我应该使用flash或canvas标签，但Scott的API非常丰富和强大......太多了，不能自己实现）。

所以，你......我只需要离开我的屁股，至少上面的物品就可以了。

特洛伊

PS - 用于测试游戏的另一个URL可能是game preview here。你可以像所有玩家一样玩整个游戏。

Answer 2

Google Page Speed会测试网站遵循最佳效果的效果，而不是实际效果如何。如果该网站在Chrome中运行缓慢，请尝试使用Google Speed Tracer，其中将分析浏览器在网站上执行的操作。比较它在windows和linux之间的输出。

Answer 3

只是一些额外的反馈：Mac OS X Firefox中的游戏似乎也令人难以置信的慢 - 不得不重新启动'狐狸冻结之后......！哎哟！

Answer 4

另一个想法。

原始API更适合使用平面区域的游戏（如Gambit和WWII）。因此，我不是生成数千个包含斑点阴影的gif（使图像更大），而是：

恢复为png，使用单一颜色，例如：蓝色，但透明度为30％，让底层板提供阴影和纹理。 OR
使用gifs，单个平面颜色，没有阴影，并使用DOM属性将其显示为半透明（这已经在一些地方使用一些不同的浏览器特定的dom属性完成）。唯一的挑战就是让它在视觉上看起来很好。

这里可能的好处是减少每个图像请求传输的数据大小。它仍然留下了大量请求的问题。

最后，有可能将这种方法与精灵方法相结合，而不是从主地图（gimp图像）渲染数千个单独的图像，而是将区域渲染为单个巨型图像（每个图像周围都有额外的透明空间）境）。

所以，我可以追求一些想法......呃，随着我的日程安排开启：）

特洛伊

Answer 5

修改

好的，这是一个可怕的设计。它加载了大量的GIF（每个区域2个），它们是比赛场地的大小（947x622）并覆盖它们。然后鼠标悬停它切换两个。无论如何，这是造成性能不佳的原因，我希望。

这有帮助吗？既然你知道它是如何被严重执行的，那真的有什么关系？只需在窗户上播放。

原帖好吧，在Windows上说一些东西很快而在Linux上说慢一点意味着没什么。你可以在一个8GB的四核上运行它，它有一个巨大的磁盘用于windows和一个用于linux的上网本。这会让它变慢。那么告诉我们......两台机器之间的技术差异是什么。我的猜测是linux机器有更少的内存，这个应用程序喜欢java和图形的大量内存。

Answer 6

我今天一直在做一些分析。这是我在这里的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个左右的突出显示区域
“pieces.gif”表示纪念碑，城市和军队人员，另外240多人

仅在屏幕上一次就有大约500个GIF，或250gifs和1个gif sprited 240次

这表明，当某个地区有彩色叠加时，我自己的底层API正在做一些非常昂贵的事情。（因为在历史的曙光中，当围绕董事会时，表现非常好。）

我可能需要查看territory.updateHtml（）中的所有代码; （是谁说这不是一个代码问题？...哈！我不认为他看到了15000行意大利面疯狂javascript我写的：o）。

也许我应该从Epoch 1运行一个类似的配置文件，看看它是什么样的？如果我发现更多，我会发布。

特洛伊

Answer 7

@Hogan＆amp; @CasualCoder，在后面的频道中已经进行了一些关于你提到的线路的讨论：由于用于彩色叠加的大尺寸图像，随着游戏的进行，性能会受到影响。游戏使用：

129突出显示图像（在鼠标悬停期间使区域发光）
92彩色叠加（显示哪个玩家拥有该地区）
用于脉冲效果的129个IMG标签（重复129个hilite图像）。

= 350个IMG标签。

在游戏开始时，92彩色叠加层是1x1像素空白图像。每个区域的亮点是1个图像，大多数是透明的，与电路板的大小相匹配，但通常只有1个可见。

随着游戏的进行，叠加图像被显示红色或蓝色等单一区域的图像所取代，具体取决于哪个玩家拥有它。这些彩色覆盖层与板相同，但大多数是透明的。当时我们认为这些图像的渲染速度与较小的裁剪图像一样快（在Windows中的一些较旧的IE浏览器中似乎就是这种情况）。

但是，基于其他一些测试结果的反馈，我得到了很多支持，这些947x622尺寸的叠加是问题所在;结合任何高光图像也可见。

对于被征服的地区，这是最多92个可见IMG的最坏情况，加上可能有十几个IMG正在为当前帝国= 105 947x622（boardize）堆叠图像进行脉冲。令人担忧的是，在Linux和Mac浏览器中移动鼠标时，这会导致极度减速。

我编辑了我的gimp脚本而不是生成尽可能紧密裁剪的高光和叠加，并将偏移X和Y数据输出到文本文件（然后我将其粘贴到代码中并用于相对于顶部定位新图像 - 董事会的左角）。

新的实现似乎在我的开发环境中表现更好（我希望我不会被localhost在这里伪造）。只要我能在线获得并进行更多测试，我就会在此处更新评论。

再次感谢反馈人员，我希望新裁剪的图形解决问题。

特洛伊

编辑：Empires的最新裁剪图片代码现已在线。只是等待更多的一般反馈，但到目前为止，似乎在Windows FF和Ubuntu FF中感觉更加响应！再次感谢大家的帮助:)。

AJAX桌面游戏在Windows中运行良好，但在Linux中运行不正常

7 个答案: