流畅得昏死过去！~~~标签、会话控好幸福！~~~~O(∩_∩)O~

测试了一下，对效果非常满意
虽然是伪·可视范围解码，但是对于一般的多图站来说已经效果非常明显了，各种流畅
但是毕竟内存占用还摆在那，出来混迟早是要还的，所以于是真的多图，该崩的还是要崩的
我也不希望变成chrome那样，真·可视范围解码，太过依赖cpu而限制ram好像不是什么合理的做法，如果可以由用户设置一个限制，比如fx最多可用40%的ram，超过额度就停止解码什么的就完美了

附上当初测试用的站点
在我的4G机器上，以前的情况是
ImageHeavyTest： 载入卡的要死，切换tab卡的要死
OOM KILL： Killed

现在的情况是：
ImageHeavyTest： 载入很快，切换tab顺畅地要死
OOM KILL： Killed

图片：2.png

所以总算是有进步的



ImageHeavyTest.7z

类型：

售价：0

大小：20KB

下载：21次

描述：

[下载]

OOM KILL.7z

类型：

售价：0

大小：64KB

下载：18次

描述：Warning： 4GB及以下内存的机器请勿轻易用firefox尝试

[下载]

楼上居然有如此测试神器，看来这个改进是有效的，而且十分明显。

附檔是網址嗎？
OOM KILL 還是 Killed 阿...?!

Platform: x86 Mac OS X

这不是说只在mac平台上么？windows和linux会有效果？？？？？？

x86 肯定有windows平台，linux应该是没有。

Linux 有 x86 阿

fang5566：x86 肯定有windows平台，linux应该是没有。回到原帖

x86是硬件平台，windows、linux都能安装在x86机子上。

趁着最近内存白菜价，235入了根8G，现在就12G内存啦
终于能如愿以偿地完成最后的测试，下面是结果。win7 x64 fx 16b5

图片：1.png

结果非常奇怪
首先没有了内存的限制（基本上），fx很快（大概2~3s）就展现出了页面，如果是nightly的话可能会更快。完全读取完毕后大概是5.6G的内存占用。未开之前是2.3G，差值3.3G左右，和理论相符合，about:memory里也报告占用3300M左右
切换标签依然很快就会释放内存，切回时再读进来。从第二个小尖峰可以看出，这个默认的释放时间还是很短的，大概在5秒左右（图中小方格）
在浏览的过程中，内存占用还会进一步升高。
奇怪的事情来了，继续往下拉页面，当内存占用升高到8G左右时（相对于读取页面完毕时增加了2.4G），内存占用停止上升，基本上不变，而这时候并不是所有图片都解码了，从图可以看出，一共339张图片，仅解码到了第88张，之后就是空白一片……这是为什么- -



顺便来个chrome对比的，好久没更新了，chromium24.0.1310.0 (164524)，就算有问题应该也黑不到cr头上，毕竟是dev

图片：2.png

初始2.84G，浏览峰值3.03G，退出后2.84G，内存基本上可以忽略占用
一般网页图片的实时解码很难让人察觉占用，但是本测试所用全为高压PNG，解码开销本身就很大，而且数量巨大，直接后果就是，虽然chrome的内存占用完爆fx，但是在如此的极端条件下，chrome虽然内存无变化，却用了近9秒才打开页面，而且拖动页面的过程中非常卡，cpu占用70%~80%，远远高于fx的20%~30%
但是页面全部显示成功，所有图片都能看到


fx无法显示所有图片这一点让我非常在意……不知道新版有没有变化……
于是我载了个fx 19a1 build20121113030658
然后非常遗憾，不知道是不是图片解码的bug，还是被kill了
nightly大概是开了debug模式啥的，需要的内存远远大于实际需要量。卡死我了。

图片：3.png

Olli Pettay [:smaug] 2012-10-06 07:11:15 PDT

I guess this is risky, since some images don't get decoded now. (I'll file a bug if I can reproduce
the problem)

Bug 792199的Comment 14 以及Bug 804000，的确可能有图片不显示的问题存在。
开发人员暂时把这个补丁去掉了。

Platform: x86 Mac OS X

此改善限定 Mac OS X?

白左：趁着最近内存白菜价，235入了根8G，现在就12G内存啦
终于能如愿以偿地完成最后的测试，下面是结果。win7 x64 fx 16b5





结果非常奇怪
首先没有了内存的限制（基本上），fx很快（大概2~3s）就展现出了页面，如果是nightly的话可能会更快。完全读取完毕后大概是5.6G的内存占用。未开之前是2.3G，差值3.3G左右，和理论相符合，about:memory里也报告占用3300M左右
切换标签依然很快就会释放内存，切回时再读进来。从第二个小尖峰可以看出，这个默认的释放时间还是很短的，大概在5秒左右（图中小方格）
在浏览的过程中，内存占用还会进一步升高。
奇怪的事情来了，继续往下拉页面，当内存占用升高到8G左右时（相对于读取页面完毕时增加了2.4G），内存占用停止上升，基本上不变，而这时候并不是所有图片都解码了，从图可以看出，一共339张图片，仅解码到了第88张，之后就是空白一片……这是为什么- -



顺便来个chrome对比的，好久没更新了，chromium24.0.1310.0 (164524)，就算有问题应该也黑不到cr头上，毕竟是dev

初始2.84G，浏览峰值3.03G，退出后2.84G，内存基本上可以忽略占用
一般网页图片的实时解码很难让人察觉占用，但是本测试所用全为高压PNG，解码开销本身就很大，而且数量巨大，直接后果就是，虽然chrome的内存占用完爆fx，但是在如此的极端条件下，chrome虽然内存无变化，却用了近9秒才打开页面，而且拖动页面的过程中非常卡，cpu占用70%~80%，远远高于fx的20%~30%
但是页面全部显示成功，所有图片都能看到


fx无法显示所有图片这一点让我非常在意……不知道新版有没有变化……
于是我载了个fx 19a1 build20121113030658
然后非常遗憾，不知道是不是图片解码的bug，还是被kill了
nightly大概是开了debug模式啥的，需要的内存远远大于实际需要量。卡死我了。
回到原帖

  这个bug不是一直都有么，大量图片的时候，有些图片不解码。

可以说Firefox长期以来对大量图片的网页，内存和卡顿处理不佳，是我对他的唯一不满。

这么多个版本了，还是不能很好的解决

等super snappy吧
可惜开发者要到11月中旬
也就是这几天才回归
异步还是不能很好的解决问题

super snappy 啥鳥？