Loading http://imgur.com/T2knu freezes my Nightly (10/24) for ~20 seconds while the image is incrementally transferred (or maybe just decoded? I didn't check). The page contains a 4000x3000 JPEG (665K), scaled to 610x458. Are we starving the event loop or something? I wouldn't have expected even large image loads to be doing this.

> Are we starving the event loop or something? Probably yes, as we async decode for a bit, then paint it all, then async decode some more, etc. I think Jeff diagnosed another similar issue recently.

Interestingly, it loads very quickly for me, with no perceptible hang. Maybe it's os-specific? I'm on Linux.

On my mac laptop, Firefox is unresponsive for the few seconds while the image is loading, but only if the image is loading off the network. If it's loading from cache, or if I'm re-decoding the image, everything is quite fast. Maybe we're painting too often on Mac or something.

This is, by far, the worst "browser locks up for multiple seconds" bug I see on OS X. (In fact, the only such bug I see in my usage.) Can we get someone looking at this?

I think Benoit might have dealt with something similar to this recently.

Moving over P1 status from dupe. I just tried this in FF 4.0 and I see no performance problem with: http://imgur.com/RX5UI While I see HUGE responsiveness issues in nightly. We should find the regression window and consider backing out. I think this is all related to high quality down scaling. I also see black scan lines in nightly while I don't see them in FF 4.0, I have a feeling it's the same changeset responsible for both.

Another example (~20sec hang while loading): https://imgur.com/r/fffffffuuuuuuuuuuuu/WfN7k (700 × 2826, 4.5MB). The image in comment 7 took at least 10 seconds (3387 × 2408 pixels, 720K)

Benoit/Jeff, can you assign this to someone on GFX?

> While I see HUGE responsiveness issues in nightly. What operating system?

It seems fine in native Fennec. I can pan and zoom around while the image loads. It loads very slowly, but I don't know if that's the fault of my network, the phone's wifi, or Fennec.

It also seems to work fine on my WinXP netbook.

The problem is worse on mac. Its related to the cairo quartz image parameters performing expensive antialiasing for each incremental decode from what Jeff told me previously.

Bug 695859 should help here.

Indeed the fix for bug 695859 seems to fix this and it should be in tomorrow's nightly. Reopen if you disagree.

Sorry; while this might be a bit better, it's still an issue.

(In reply to Joe Drew (:JOEDREW!) from comment #16) > Sorry; while this might be a bit better, it's still an issue. On what platform(s)?

Yeah, I still see this with a OS X 1/8 Nightly. Seems less common, but I can reproduce by shift-reloading a large image (standalone, scaled by default). Eg http://upload.wikimedia.org/wikipedia/commons/a/ad/M1_Abrams_turret_fire_above.jpg Takes about 10 seconds to load on my current network connection, the browser isn't totally frozen, but it takes 2 or 3 seconds to switch tabs while it's loading.

(In reply to Justin Lebar [:jlebar] from comment #17) > (In reply to Joe Drew (:JOEDREW!) from comment #16) > > Sorry; while this might be a bit better, it's still an issue. > > On what platform(s)? OS X.

(In reply to Justin Dolske [:Dolske] from comment #18) > Yeah, I still see this with a OS X 1/8 Nightly. Seems less common, but I can > reproduce by shift-reloading a large image (standalone, scaled by default). > > Eg > http://upload.wikimedia.org/wikipedia/commons/a/ad/ > M1_Abrams_turret_fire_above.jpg > > Takes about 10 seconds to load on my current network connection, the browser > isn't totally frozen, but it takes 2 or 3 seconds to switch tabs while it's > loading. The problem has gotten a lot better, but I still see us spending a lot of time redrawing the image. Here's a profile I collected with my experimental gecko profiler, you should be able to open this up directly: http://varium.fantasytalesonline.com/cleopatra/?report=AMIfv97fOH8ndg-dTer5Pte8E9Ud1y92YqKIP_fnSWOnUV79hUvPuHrnq1SYj1VfECd11ekfhk3w-v7KU7OYZVzg28flArkOPBhYpVh1_FUIlIehbtNqy_DloHjykWBH0g5oAcq3bAnkK5AOaBJmhXOm1ggkE9LF1Q Select 'CGSBlendRGBA8888toRGBA8888' and then select it's range in the histrogram. This will give you the sample relevant to the image decoding period. The fades from black to red means that CGSBlendRGBA8888toRGBA8888 is preventing us from responding to events. In this period we only responded to events 2-3 times over ~3 seconds.

I can't reproduce this bug in latest Nightly. Is it still reproducible for someone?

Can't reproduce either with MacOS X + Nightly, even with Ghostery (which used to kill us at image loading).

I don't see the problem. Let's call it WFM unless BenWa still wants to look at CGSBlendRGBA8888toRGBA8888 for some reason.