1217623 - Extreme lag on image website

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P1)

Description

[hiukuss]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20151014143721

Steps to reproduce:

I browse www.funnyjunk.com regularly.
Whenever I click on an image to view, or the website's Next Picture button, it takes ~10 seconds to load.


Actual results:

The image (depending on size) takes a very long time to load.
I tested with multiple browsers.
Chrome loads normally.
Firefox is slow.
Waterfox is slow.
Internet Explorer loads normally.


Expected results:

Instantaneous loading across all platforms

Comment 1

[ovidiu boca[:Ovidiu]]

Hi, 

I can reproduce this bug on Windows 7 64 bit on Firefox Nightly 44.0a1 (2015-10-23).

Steps to reproduce:

1 Open Firefox
2 Go to www.funnyjunk.com
3 Click on the website's Next Picture Button or click on a image to view.

Expected results:

The image takes a very long time to load.
Loading is almost instantaneous 

Actual results:
 The image takes a very long time to load, approx.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Does the performance improve if you disable e10s[1]?

Can we get a copy of your about:support?

[1]: https://wiki.mozilla.org/Electrolysis#Enabling_and_Disabling_Electrolysis

Comment 3

[ovidiu boca[:Ovidiu]]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #2)

> Does the performance improve if you disable e10s[1]?

Yes I notice an improvement.
 
> Can we get a copy of your about:support?


Graphics
Adapter Description	ATI Radeon 3000 Graphics
Adapter Drivers	aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM	512
Asynchronous Pan/Zoom	none
Device ID	0x9616
Direct2D Enabled	true
DirectWrite Enabled	true (6.2.9200.17461)
Driver Date	4-29-2013
Driver Version	8.970.100.1100
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 11 (OMTC)
Subsys ID	00000000
Supports Hardware H264 Decoding	No; Failed to find an appropriate decoder GUID
Vendor ID	0x1002
WebGL Renderer	Google Inc. -- ANGLE (ATI Radeon 3000 Graphics Direct3D11 vs_4_0 ps_4_0)
windowLayerManagerRemote	true
AzureCanvasBackend	direct2d 1.1
AzureContentBackend	direct2d 1.1
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

> 
> [1]:
> https://wiki.mozilla.org/Electrolysis#Enabling_and_Disabling_Electrolysis

Comment 4

[Mike Conley (:mconley) (:⚙️)]

I wonder if this is related to bug 1213432, since you're using D3D11.

Can you please test again with e10s enabled, but with hardware acceleration disabled? Does that improve things?

Comment 5

[ovidiu boca[:Ovidiu]]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #4)
> I wonder if this is related to bug 1213432, since you're using D3D11.
> 
> Can you please test again with e10s enabled, but with hardware acceleration
> disabled? Does that improve things?

I have tested again with e10s enabled, but with hardware acceleration disabled. Things are not improve.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Hey ovidiu,

We know that the imagelib cache is busted with e10s (bug 1217571), and we're wondering if this is related to that. One way to confirm is to disable the imagelib cache with non-e10s, and compare against e10s. If after you disable the cache, both browsers have comparable performance, that would bolster the case that fixing bug 1217571 would fix this bug.

Can you please set image.cache.size to 0 in about:config for the non-e10s profile and let us know if the performance becomes comparable to e10s?

And can you also provide a list of your enabled add-ons?

Thanks!

Comment 7

[ovidiu boca[:Ovidiu]]

Hi Mike,

I have tested the problem on FF Nightly 45.0a1(2015-11-10) with e10s enable and also with e10s disable where I set the image.cache.size to 0 and everything is working normal, the results are the same in booth cases. I don't have add-ons. Please tell me if I can provide more info.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

That seems consistent with our theory that making the imagelib cache work with e10s will fix this.

Thanks ovidiu!

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

Can you still reproduce this now that the image cache is fixed?

Comment 10

[Sylvestre Ledru [:Sylvestre]]

is this issue a windows 64bit only?

Comment 11

[Mike Conley (:mconley) (:⚙️)]

(In reply to Sylvestre Ledru [:sylvestre] from comment #10)
> is this issue a windows 64bit only?

This was originally reported on a 64-bit machine, but (as far as I know), the imagelib cache works the same way between 32 and 64 bit machines.

So assuming the imagelib cache was the problem here, this should not have been a 64 bit machine problem only.

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

Resolving WFM.