5 ms·

Firefox is still far behind in rendering images, something that's untested in this benchmark. In real world use this makes FF slow as hell. I really do hope FF

Firefox is still far behind in rendering images, something that's untested in this benchmark. In real world use this makes FF slow as hell. I really do hope FF catches up.

ksec 13y ago
Can you elaborate on that? I am pretty sure those bugs about rendering ( lots ) of images were fix a few versions ago.
- bri3d 13y ago
  It looks like they tried to land a patch which would discard images that were outside of the viewport, but it broke so they backed it out of FF 22 ( https://bugzilla.mozilla.org/show_bug.cgi?id=872235 https://bugzilla.mozilla.org/show_bug.cgi?id=872235 ). Then, there's https://bugzilla.mozilla.org/show_bug.cgi?id=847223 https://bugzilla.mozilla.org/show_bug.cgi?id=847223 where all downloaded images are decoded and live forever regardless of if they are shown.
  - nnethercote 13y ago
    The backed-out-of-FF22 patch has been fixed and is present and enabled in FF24 (currently in Aurora). > all downloaded images are decoded and live forever regardless of if they are shown. Nope. Before the backed-out-of-FF22 patch landed, all images in a page were decoded and kept in memory as long as that page was in the foreground. But if you switched to another tab, the decoded images would be discarded. With the backed-out-of-FF22 patch in place, most images that are downloaded are decoded temporarily, but those that aren't visible are discarded quickly. When bug 847223 is done, the not-visible images won't even be decoded on page loading. So, to summarize: in FF24, on image-heavy pages you'll see a memory spike on first load, but it'll quickly drop down. And once bug 847223 is done (hopefully soon, though these things are hard to predict), you won't even see that spike.
padenot 13y ago
I you are talking about rendering speed, you'll be pleased to know that people have been working on multithreaded image decoding. Not sure when it will be available in release, but it is in my Firefox Nightly.
- asb 13y ago
  There's still more to do on optimising rendering for pages with lots of images, see https://blog.mozilla.org/nnethercote/2013/06/15/memshrinks-2nd-birthday/ https://blog.mozilla.org/nnethercote/2013/06/15/memshrinks-2.... I've got my eye on https://bugzilla.mozilla.org/show_bug.cgi?id=847223 https://bugzilla.mozilla.org/show_bug.cgi?id=847223
- pjriot 13y ago
  Not that this should be considered proof, but I just compared nightly and 22 side by side on Ubuntu 12.10 (Unity) and I can certainly perceive an appreciable difference. Great stuff.
pcwalton 13y ago
What bugs are you referring to? Images are now decoded off the main thread (in nightly) and are not decoded until you scroll to them.
- bri3d 13y ago
  Per (0) I don't think "don't decode until you scroll" is done yet. This issue alone makes Firefox annoying for use on image boards and "infiniscroll"-style galleries like Facebook's. Also, "discard images when you scroll them offscreen" was disabled in (1) because it broke sites with lots of images (like Pinterest and Tumblr Archives, according to the bug). These two issues alone make Firefox pretty painful for a lot of common use cases on real-world machines (like my old web browsing machine with only 2GB of RAM). (0): https://bugzilla.mozilla.org/show_bug.cgi?id=847223 https://bugzilla.mozilla.org/show_bug.cgi?id=847223 (1): https://bugzilla.mozilla.org/show_bug.cgi?id=872235 https://bugzilla.mozilla.org/show_bug.cgi?id=872235
  - nnethercote 13y ago
    Bug 689623's fix is re-enabled in FF24, which is currently in Aurora. It goes a long way towards fixing the problems with image-heavy pages. And bug 847223 should fix them completely once it's done; there are numerous patches but some haven't passed code review, so it's unclear how much longer it'll take.
atestu 13y ago
It's also pretty bad at rendering SVG, I don't understand why this wasn't tested considering the popularity of the d3.js library.
agumonkey 13y ago
And there are some bad corner cases on numerous large images html leading to memory consumption so fast (1GB+ in a few seconds) your system will soon swap to hell and probably stop responding.

Firefox is still far behind in rendering images, something that's untested in this benchmark. In real world use this makes FF slow as hell. I really do hope FF catches up.

ksec 13y ago

Can you elaborate on that? I am pretty sure those bugs about rendering ( lots ) of images were fix a few versions ago.

bri3d 13y ago
It looks like they tried to land a patch which would discard images that were outside of the viewport, but it broke so they backed it out of FF 22 ( https://bugzilla.mozilla.org/show_bug.cgi?id=872235 https://bugzilla.mozilla.org/show_bug.cgi?id=872235 ). Then, there's https://bugzilla.mozilla.org/show_bug.cgi?id=847223 https://bugzilla.mozilla.org/show_bug.cgi?id=847223 where all downloaded images are decoded and live forever regardless of if they are shown.
- nnethercote 13y ago
  The backed-out-of-FF22 patch has been fixed and is present and enabled in FF24 (currently in Aurora). > all downloaded images are decoded and live forever regardless of if they are shown. Nope. Before the backed-out-of-FF22 patch landed, all images in a page were decoded and kept in memory as long as that page was in the foreground. But if you switched to another tab, the decoded images would be discarded. With the backed-out-of-FF22 patch in place, most images that are downloaded are decoded temporarily, but those that aren't visible are discarded quickly. When bug 847223 is done, the not-visible images won't even be decoded on page loading. So, to summarize: in FF24, on image-heavy pages you'll see a memory spike on first load, but it'll quickly drop down. And once bug 847223 is done (hopefully soon, though these things are hard to predict), you won't even see that spike.

padenot 13y ago

I you are talking about rendering speed, you'll be pleased to know that people have been working on multithreaded image decoding. Not sure when it will be available in release, but it is in my Firefox Nightly.

asb 13y ago
There's still more to do on optimising rendering for pages with lots of images, see https://blog.mozilla.org/nnethercote/2013/06/15/memshrinks-2nd-birthday/ https://blog.mozilla.org/nnethercote/2013/06/15/memshrinks-2.... I've got my eye on https://bugzilla.mozilla.org/show_bug.cgi?id=847223 https://bugzilla.mozilla.org/show_bug.cgi?id=847223
pjriot 13y ago
Not that this should be considered proof, but I just compared nightly and 22 side by side on Ubuntu 12.10 (Unity) and I can certainly perceive an appreciable difference. Great stuff.

pcwalton 13y ago

What bugs are you referring to? Images are now decoded off the main thread (in nightly) and are not decoded until you scroll to them.

bri3d 13y ago
Per (0) I don't think "don't decode until you scroll" is done yet. This issue alone makes Firefox annoying for use on image boards and "infiniscroll"-style galleries like Facebook's. Also, "discard images when you scroll them offscreen" was disabled in (1) because it broke sites with lots of images (like Pinterest and Tumblr Archives, according to the bug). These two issues alone make Firefox pretty painful for a lot of common use cases on real-world machines (like my old web browsing machine with only 2GB of RAM). (0): https://bugzilla.mozilla.org/show_bug.cgi?id=847223 https://bugzilla.mozilla.org/show_bug.cgi?id=847223 (1): https://bugzilla.mozilla.org/show_bug.cgi?id=872235 https://bugzilla.mozilla.org/show_bug.cgi?id=872235
- nnethercote 13y ago
  Bug 689623's fix is re-enabled in FF24, which is currently in Aurora. It goes a long way towards fixing the problems with image-heavy pages. And bug 847223 should fix them completely once it's done; there are numerous patches but some haven't passed code review, so it's unclear how much longer it'll take.

atestu 13y ago

It's also pretty bad at rendering SVG, I don't understand why this wasn't tested considering the popularity of the d3.js library.

agumonkey 13y ago

And there are some bad corner cases on numerous large images html leading to memory consumption so fast (1GB+ in a few seconds) your system will soon swap to hell and probably stop responding.