Large pictures take long time to load in TFF 8

[GoogleCodeExporter]

I notice a severe speed decrease when loading large jpg pictures (images that 
are large enough to be scaled down in the browser window), starting with TFF 8 
beta1, compared to TFF 7 and before. It doesn't matter if the picture is loaded 
within a website or as a single file, or from the hard drive or the web. TFF 7 
and FF 8 (on Win XP) behave as expected, TFF 8 doesn't.

STR:
1) Download the jpg picture attached, unzip, and keep on the hard drive to rule 
out network speed changes. (I chose this picture because it's so large that it 
should demonstrate the effect on any computer running TFF.)
2) Create a new OS X user for testing purposes.
3) Start TFF 7.0 and drop the picture (or any very large jpg) into the browser 
window in a new tab (or load with the file open dialog). Observe loading speed. 
Clear cache in-between.
4) Now start TFF 8.0 and do the same. Observe loading speed.

My tests with largepicture.jpg:

TFF 7.0 G4 7450 1.3 GHz: ~2 sec. (10.5.8)
TFF 7.0 G3 400 MHz: 10 sec. (10.4.11)
vs.
TFF 8.0 G4 7450 1.33 GHz: 33 sec. (10.5.8)
TFF 8.0 G3 400 MHz: 240 sec. (10.4.11)
vs.
FF 8.0 VirtualPC emulated ~300 MHz Pentium II: 8 sec. (XP SP3)

How can that be? And I do believe that the problem is not the loading itself, 
but the scaling.

Original issue reported on code.google.com by chtru...@web.de on 29 Nov 2011 at 9:58

Attachments:

• largepicture.jpg.zip

[GoogleCodeExporter]

Correction: 
Ø  TFF 8.0 G4 7450 1.33 GHz: 33 sec. (10.5.8)
-> TFF 8.0 G4 7450 1.33 GHz: 13 sec. (10.5.8) (but you get the point)

Original comment by chtru...@web.de on 29 Nov 2011 at 10:10

[GoogleCodeExporter]

Hmmmmm. It's just as bad in 9.

Clearly the JPEG AltiVec decoder isn't to blame (in fact, it's the reason it's 
not anywhere near as bad as the G3), so we know it's not a regression from that.

Original comment by classi...@floodgap.com on 30 Nov 2011 at 4:22

[GoogleCodeExporter]

(taking)

Original comment by classi...@floodgap.com on 30 Nov 2011 at 4:22

[GoogleCodeExporter]

It's indeed the scaling because as soon as you click in the picture to turn off 
downscaling decoding finishes nearly instantly with the above test jpg on a G4 
1.5 GHz.

Original comment by Tobias.N...@gmail.com on 30 Nov 2011 at 6:47

[GoogleCodeExporter]

Did some more testing using a >9 MB jpg to compare TFF8 G3 and G4 7450 builds 
in decoding speed.
I didn't take the time to wait for it to decode in downscaled mode the G3 build 
was very roughly 50% faster. Decoding the whole picture would have taken 
approx. 2 minutes using the 7450 build and 1 minute using the G3 build.
In native size mode the decoding took 10 seconds using the G3 build and 13 
seconds using the 7450 build. I started to count the seconds when the first 
lines started to show.

So it seems that in TFF8 the AltiVec decoder performs bad. TFF doesn't feed 
jpeg data to the decoder in a way the AltiVec decoder likes it. But maybe that 
changes when the real issue for generally slower jpeg decoding is solved.

Original comment by Tobias.N...@gmail.com on 30 Nov 2011 at 7:14

[GoogleCodeExporter]

I think we need to figure out what Mozilla "broke."
http://www.mozilla.org/en-US/firefox/8.0/releasenotes/buglist.html

There are some scaling-related changes in there which I will start 
investigating.

Original comment by classi...@floodgap.com on 30 Nov 2011 at 2:31

[GoogleCodeExporter]

This looks VERY suspicious.
https://bugzilla.mozilla.org/show_bug.cgi?id=666352

Original comment by classi...@floodgap.com on 30 Nov 2011 at 4:27

[GoogleCodeExporter]

If 666352 is indeed the cause, these are the prefs we might want to mess with:

+// We decode this many bytes before yielding to the main event loop when we
+// first asynchronously decode an image.  When we come back and decode the next
+// part of this image, the amount we decode is determined by how quickly we
+// decoded the previous block.
+pref("image.mem.initial_decode_block_size", 1024);
+
+// We always decode images in blocks whose size is a multiple of this value.
+pref("image.mem.decode_block_size_multiple", 1024);
+
+// The number of milliseconds we aim to spend in one iteration of an async 
decode
+pref("image.mem.ms_before_yield", 5);
+
+// The minimum amount of time between two consecutive flushes to the screen of
+// a partially-decoded image
+pref("image.mem.ms_between_updates", 50);

Original comment by classi...@floodgap.com on 30 Nov 2011 at 4:29

[GoogleCodeExporter]

image.mem.max_bytes_for_sync_decode may also be worth increasing.

Original comment by classi...@floodgap.com on 30 Nov 2011 at 4:37

[GoogleCodeExporter]

http://hg.mozilla.org/mozilla-central/diff/fa82e3fa46b9/modules/libpref/src/init
/all.js

I think reverting this will be the safest and biggest win. I will look at this 
this evening when I'm on the G5. This could be sneaked into 9b1, a pref-only 
change would be safe.

Original comment by classi...@floodgap.com on 30 Nov 2011 at 5:38

[GoogleCodeExporter]

Yes, that's the problem. When I changed those two prefs, the provided image 
appears in about 3 wall-clock seconds, scaled, on the quad G5 in reduced mode. 
Without it, it takes it close to 20 seconds. So we will ship this change in 
9b1, and I will make a note of this to Mozilla.

Original comment by classi...@floodgap.com on 1 Dec 2011 at 12:45

• Changed state: Started

[GoogleCodeExporter]

Confirmed fixed in 9.0b1.

Original comment by chtru...@web.de on 2 Dec 2011 at 9:19

[GoogleCodeExporter]

Mozilla doesn't seem too interested in this. Figures.

Original comment by classi...@floodgap.com on 3 Dec 2011 at 12:58

• Changed state: Verified

[GoogleCodeExporter]

Just for yuks, https://bugzilla.mozilla.org/show_bug.cgi?id=811467

Our current values seem to work well, though, so we'll just keep what we have.

Original comment by classi...@floodgap.com on 14 Nov 2012 at 3:49