There is a significant delay when loading images after scrolling on websites such as instagram or imgur using a GeckoView product such as the reference browser or focus.

Steps to reproduce:

1. Navigate to https://www.instagram.com/justintimberlake/?hl=en
2. Scroll down a few pages to load some images.
3. Now scroll up or down on the pages you loaded. There is a white blank screen, or sometimes the borders appear, but the images show up a long time afterwards.

This is only reproducible on lower end devices like the G5. I wasn't able to see this on the Pixel 2, at least not to the same extent. Chrome doesn't have this problem and the images appears instantly when scrolling there.

Profile with screenshots:
http://bit.ly/2FWHJjB

Profile without screenshots (less overhead):
http://bit.ly/2FUebTP

I have some screen captures of this as well. If interested, please contact me since they are very large.

I filed bug 1522288 about one problem I see in the profile: We don't start loading the images from the network until the main thread stops running JS.

(In reply to Markus Stange [:mstange] from comment #1)

I filed bug 1522288 about one problem I see in the profile: We don't start loading the images from the network until the main thread stops running JS.

It looks to me like the JS that triggers the images loading is only running near the end, it seems to fire based on a Promise callback. Some ordering stuff might be involved here, but the content thread appears to be idle plenty of times before this point.

We're making this QF P1 pageload because we should investigate what happens here some more. For example, here's a period in the profile where we're running three refresh ticks while the screen is blank and the network is idle: http://bit.ly/2CMNeP0
Bug 1522288 might help start the image loads earlier during the last refresh tick, so then we'd be down to 2.5 idle blank refresh ticks. I'd expect us to be able to do better than 2.5 though. We should also compare to Chrome.

Gathered some profiles for this behavior for Reference Browser (nightly) using imgur. The delay is noticeable, but not as bad as in the videos. I was not happy with the profiles that I gathered -- I will get better, more complete ones tomorrow and then post links to them here.

I have tested with the WIP patch from 1522288 and I am gathering some updated profiles. It seems like this is a really big improvement. More tests to come and I will attach profiles if the problem continues.

This are much better thanks to smaug's patch.

https://perfht.ml/2X69xIH

That is fennec build from moz-central with his patch applied.

What is obvious is that the network requests (for images) begin much more quickly. There is still some delay in certain cases. For instance, I investigated the image with the "name" 1lU71I7_d.jpg. The LoadImage for that thumbnail is called around 23.3 seconds into the profile. The actual network request starts around 23.6 seconds.

That's significantly better than in previous profiles.

It would be great if denispal could confirm that he is seeing better performance after applying this patch.

Also, smaug, what would it take to turn your patch into something real rather than a WIP? Since it seems to help, I would imagine that we want to get it landed. Can I help, please?

Turning the WIP into a patch to be reviewed requires someone to read the spec algorithm about image loading and verifying the patch isn't too badly against it.

Relevant links are in https://bugzilla.mozilla.org/show_bug.cgi?id=1522288#c7

And links to some background information in
https://bugzilla.mozilla.org/show_bug.cgi?id=1522288#c6
https://bugzilla.mozilla.org/show_bug.cgi?id=1522288#c5

Thanks to mstange's suggestion, I profiled in geckoview_example so that we could see how it performs in multiprocess mode. Here is the resulting profile:

https://perfht.ml/2S1orw5

Here is a profile that is done correctly (again, thanks to mstange). This does not include the overhead of the developer tools.

https://perfht.ml/2SdAKFJ

Unfortunately I don't see much improvement from the patch in 1522288 when I incorporate it into r-b. When I scroll up or down after a few of the images are first loaded, there is still quite a long delay before the images are displayed and it's night and day compared to Chrome where the images are almost instant.

I could reproduce the behaviour by scrolling very fast, and I also saw Chrome had the same behaviour.

Were you just slowly scrolling the page or you did it very fast, Denis?

Moto G5 Geckoview_example (Screenshot on): https://perfht.ml/2KIsgGA
Moto G5 Geckoview_example (Screenshot off): https://perfht.ml/2KIPiwX

(In reply to Sean Feng [:sefeng] from comment #11)

I could reproduce the behaviour by scrolling very fast, and I also saw Chrome had the same behaviour.

Were you just slowly scrolling the page or you did it very fast, Denis?

Moto G5 Geckoview_example (Screenshot on): https://perfht.ml/2KIsgGA
Moto G5 Geckoview_example (Screenshot off): https://perfht.ml/2KIPiwX

Yes, I did the same test. However, my experience was different. I saw GVE took about 5s to load the images while Chrome was under 1s. I would just scroll down a few pages first, if you didn't do that, to preload some of the images. Then as you scroll up you can see how long it takes.

https://perfht.ml/2X5sxFX, this is the profile from simpleperf, I see the ImgDecoder threads seems very busy, and I wonder if we have concerns here.

Thoughts, Markus?

The pref image.multithreaded_decoding.limit controls the number of img decode threads. Defaults to number of cores minus 1. Try increasing it and decreasing it to see if that improves the performance on this testcase.

Thanks Timothy, I tried to change image.multithreaded_decoding.limit to 1,2 and 12, however none of them provided a noticeable differences to me.

I am able to profile ImgDecoder threads with Gecko profiler now, and it seems fine. So I think I was wrong, I don't it was ImgDecoder threads made us slow.

Default , which is 7 decoder thread on my 8 core Moto G5 : https://perfht.ml/2X8F1fW

The above one has wrong symbols, this is the correct one : https://perfht.ml/2X9NgIw

This is arm32 specific, so going to knock it down to qf:p3. I cannot reproduce it on higher end devices.