Open Bug 1363015 Opened 7 years ago Updated 2 months ago

Images are reloaded and redrawn when e10s is on and bypass cache and cause a huge jank and high CPU/Ram/Bandwidth usage

Categories

(Core :: Graphics: ImageLib, defect, P3)

defect

Tracking

()

UNCONFIRMED

People

(Reporter: jaruvova, Unassigned)

References

()

Details

(Keywords: perf, regressionwindow-wanted, Whiteboard: [gfx-noted])

Attachments

(9 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 10.0; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20100101

Steps to reproduce:

This only happens with e10s on so first disable it 
new profile

with preferably Fx50/or any other with e10s off
Visit the page 

http://imgur.com/gallery/JdJo9

and wait for the page to load completely.
scroll down and click load more
pictures start loading.

Now 
on Fx55
turn on e10s and visit the page and wait for it to load,
click load more .


Actual results:

The image at the top which were already loaded are once again loaded/redrawn from the beginning




Expected results:

The images already loaded should have stayed loaded and not reloaded just like with e10s off,
they are bypassing cache & are redrawn for no reason and again use cpu/ram/bandwidth and janks which is a critical flaw as well as it looks and feels sluggish/slow


Chrome/EDGE do this just fine and don't use excess bandwidth or CPU/RAM
Component: Untriaged → Layout: Images
Product: Firefox → Core
Version: 55 Branch → Trunk
tested this on three different machines with fresh setup,
with e10s off works fine but with e10s on causes janks/reflow/redraws/reloading/blinking pages for just a bit.
Chrome/EDGE do this just fine and don't use excess bandwidth or CPU/RAM
Don't know what else should be filled here so may be you guys can help filling up the necessary stuff.
Severity: normal → critical
Component: Layout: Images → Untriaged
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(ethlin)
Flags: needinfo?(ehsan)
OS: Unspecified → All
Priority: -- → P1
Product: Core → Firefox
Hardware: Unspecified → All
Version: Trunk → 55 Branch
Oops don't know what happened while submitting,
browser just hung up and then page reloaded, 

Urghhhhhh sorry don't know how to undo here
Component: Untriaged → ImageLib
Product: Firefox → Core
Has Regression Range: --- → yes
Has STR: --- → yes
I can't reproduce.
Has Regression Range: yes → no
This needs a proper regression window, not just "between 55 and 50", if indeed it is a regression. Don't spam other bugs and users without knowing what is the actual cause or who would be a good person to ask.

So, in 55, does this reproduce for you with e10s disabled? Are there actual extra network requests, or are we just redrawing? It's not clear from the description in this bug.
Has Regression Range: no → ---
Component: ImageLib → Untriaged
Flags: needinfo?(jaruvova)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(ethlin)
Flags: needinfo?(ehsan)
Product: Core → Firefox
It looks to me like you're basically describing checkerboarding when we do scrolling/painting off-main-thread, for which loading more images isn't necessary. I don't see anything else.
(In reply to :Gijs from comment #4)
> This needs a proper regression window, not just "between 55 and 50", if
> indeed it is a regression. Don't spam other bugs and users without knowing
> what is the actual cause or who would be a good person to ask.
> 
> So, in 55, does this reproduce for you with e10s disabled? Are there actual
> extra network requests, or are we just redrawing? It's not clear from the
> description in this bug.

I dont know how to get a regression windows.

Yes in Fx55 this can be produced with e10s on, with it off it works fine just like it should.

Some times there are request in console window with get ` url..
and redrawing is always there.

(In reply to :Gijs from comment #5)
> It looks to me like you're basically describing checkerboarding when we do
> scrolling/painting off-main-thread, for which loading more images isn't
> necessary. I don't see anything else.

Just goto the page with e10s on,
clear cache,
let the page load & then click load more and just scroll up to any of the few loaded images(which were loaded earlier)
they are reloaded or redrawn
Flags: needinfo?(jaruvova)
(In reply to Marco Castelluccio [:marco] from comment #3)
> I can't reproduce.

(In reply to :Gijs from comment #5)
> It looks to me like you're basically describing checkerboarding when we do
> scrolling/painting off-main-thread, for which loading more images isn't
> necessary. I don't see anything else.

I just did and it's easily noticeable,
The drawn images are lost and redrawn or reloaded basically.

STR:
clear cache

goto the page and let it load,
loading complete just look at image 1,2,3,
scroll down click load more,
scroll up to the top to see images 1,2,3.

They are reloaded again.
Tested on FF54
after clicking load more and scrolling up

with e1os off you get 2 image always,

with e10s on image 1 for briefly
try with a very slow connection like 2g and you will see it

also see comment 8 & 9 which describes a bit better.

with e10s off images are not lost or redrawn with e10s on they are,
plus multiple users confirmed it.
Flags: needinfo?(mcastelluccio)
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to jaruvova from comment #10)
> try with a very slow connection like 2g and you will see it

This still doesn't make sense. The previous comments indicate there are no extra network requests - how does the network connection make a difference?
Flags: needinfo?(mcastelluccio)
Flags: needinfo?(jaruvova)
Flags: needinfo?(gijskruitbosch+bugs)
I also see the delayed image redraw with non-e10s when scrolling fast enough.
(In reply to jaruvova from comment #8)
> Created attachment 8865598 [details]
> user reproduced it on mozillazine

This looks like we discarded the decoded image data, so we will trigger another decode and then paint the image. That is the expected behaviour as we don't keep around the decoded image data for every image all the time.
(In reply to Timothy Nikkel (:tnikkel) from comment #13)
> (In reply to jaruvova from comment #8)
> > Created attachment 8865598 [details]
> > user reproduced it on mozillazine
> 
> This looks like we discarded the decoded image data, so we will trigger
> another decode and then paint the image. That is the expected behaviour as
> we don't keep around the decoded image data for every image all the time.

And that is the same e10s or non-e10s, and it's been that way for a very long time (many years).
(In reply to Timothy Nikkel (:tnikkel) from comment #14)
> (In reply to Timothy Nikkel (:tnikkel) from comment #13)
> > (In reply to jaruvova from comment #8)
> > > Created attachment 8865598 [details]
> > > user reproduced it on mozillazine
> > 
> > This looks like we discarded the decoded image data, so we will trigger
> > another decode and then paint the image. That is the expected behaviour as
> > we don't keep around the decoded image data for every image all the time.
> 
> And that is the same e10s or non-e10s, and it's been that way for a very
> long time (many years).

sorry but in non e10s it does not happen, with e10s it does.
image.mem.allow_locking_in_content_processes is true by default

And why would it discard just because pressed load more ? Does that make sense as it requires more power
and even if user is on the page and no other pages open or low ram or anything.
even tried setting image.decode-immediately.enabled true

their was a pref before image.mem.min_discard_timeout_ms which used to discard with time tick like 30 sec or more and it's not there & what does image.cache.timeweight do?


Noob so don't know the details but made a video that it not only redraws(for no reason),
images start to load again from network.
Flags: needinfo?(tnikkel)
Flags: needinfo?(jaruvova)
Flags: needinfo?(gijskruitbosch+bugs)
Attached video e10s off and fresh copy
(In reply to jaruvova from comment #15)
> Noob so don't know the details but made a video that it not only redraws(for
> no reason),
> images start to load again from network.

The button says "load 30 more images" for me on the link in comment #0. The one in the URL field for the bug says "load 74 more images". Why does yours say "926 more images"? Is it not one of the two links here? Is this a clean profile or is some add-on interfering with the fetching here? How much RAM does your machine have? Have you actually verified network requests are happening (the video doesn't show devtools or wireshark or anything else), and if so, how?

In any case, I'm really not the right person to help here.
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to :Gijs from comment #18)
> (In reply to jaruvova from comment #15)
> > Noob so don't know the details but made a video that it not only redraws(for
> > no reason),
> > images start to load again from network.
> 
> The button says "load 30 more images" for me on the link in comment #0. The
> one in the URL field for the bug says "load 74 more images". Why does yours
> say "926 more images"? Is it not one of the two links here? Is this a clean
> profile or is some add-on interfering with the fetching here? How much RAM
> does your machine have? Have you actually verified network requests are
> happening (the video doesn't show devtools or wireshark or anything else),
> and if so, how?
> 
> In any case, I'm really not the right person to help here.

No just http://imgur.com/a/BtVmD is the link i used, the difference you can see yourself.

32gb ram is present, fresh profile like i mentioned before.
have NetWorx installed which shows network activeness when pressing the button.
But that'sthe secondary point, the MAIN point is why are the images discarded in e10s so quickly?

only happens with e10s ,redraws or reload etc.

plus just provide a preference to use disk cache & ram cache unlimited for users who want to use full/user choice disk and ram cache.

Similar to image.multithreaded_decoding.limit= -1 which can use all 16 threads

Thank you just wanted to show that i was telling the truth.
Flags: needinfo?(mconley)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(ehsan)
In the e10s video are you doing anything besides clicking on the "load more" button? A screencap with the page scrollbar would help to tell what is going on. If you aren't doing anything else then that doesn't look like what I would expect. Does the same thing happen with addons disabled or safe mode or a fresh profile?
Flags: needinfo?(tnikkel)
(In reply to Timothy Nikkel (:tnikkel) from comment #20)
> In the e10s video are you doing anything besides clicking on the "load more"
> button? A screencap with the page scrollbar would help to tell what is going
> on. If you aren't doing anything else then that doesn't look like what I
> would expect. Does the same thing happen with addons disabled or safe mode
> or a fresh profile?

It's a fresh profile without any changes,
just clicking load more and scrolling with mouse wheel.
Not doing anything else.
Flags: needinfo?(tnikkel)
Can reproduce this on three different laptops with a new profile.

bug 1361388 also might be related to this as can reproduce it with e10s on too.
Plus updating blockers as this is a major regression for those and might degrade UX for most users.
Blocks: 1361388
jaruvova, firstly, *please* stop needinfo-ing random people and linking this bug to random bugs.  This doesn't come across as very respectful and will eventually cause people to end up ignoring you, which I think isn't your intention.  Clearly you are seeing a bug that you are very passionate about.  I tried going to http://imgur.com/gallery/BE5iT to try to reproduce myself without any luck.  That may suggest that there is something that causes the bug happen for you but not for me, so you can help us figure out what broke it.

There is a tool called mozregression that allows you to find a regression range that basically tells us what code change first broke something for you.  You can find it plus documentation at http://mozilla.github.io/mozregression/.  Are you willing to run it to help us find out what caused the change you are seeing?  A command like |mozregression --good 50 --bad 55| will start a regression detection between Firefox 50 and 55, but you may want to try to run mozregression --launch 51/52/etc to try out more recent versions first to find a narrower regression range.  It may be easier to do this if you start from a narrower regression range.

Thank you!
Flags: needinfo?(tnikkel)
Flags: needinfo?(mconley)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(ehsan)
(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #23)
> jaruvova, firstly, *please* stop needinfo-ing random people and linking this
> bug to random bugs.  This doesn't come across as very respectful and will
> eventually cause people to end up ignoring you, which I think isn't your
> intention.  Clearly you are seeing a bug that you are very passionate about.
> I tried going to http://imgur.com/gallery/BE5iT to try to reproduce myself
> without any luck.  That may suggest that there is something that causes the
> bug happen for you but not for me, so you can help us figure out what broke
> it.
> 
> There is a tool called mozregression that allows you to find a regression
> range that basically tells us what code change first broke something for
> you.  You can find it plus documentation at
> http://mozilla.github.io/mozregression/.  Are you willing to run it to help
> us find out what caused the change you are seeing?  A command like
> |mozregression --good 50 --bad 55| will start a regression detection between
> Firefox 50 and 55, but you may want to try to run mozregression --launch
> 51/52/etc to try out more recent versions first to find a narrower
> regression range.  It may be easier to do this if you start from a narrower
> regression range.
> 
> Thank you!


Ah sorry new here though need info was the right way.

Yes willing to help that why created an account and filed a bug.

Mozreg seems a bit too much for noob like me but willing to try.
what should i look for with respect to this bug?
How  do i know what am i looking for?

can you please tell which version was e10s initially released ?
want to test it from there.
Flags: needinfo?(ehsan)
(In reply to jaruvova from comment #24)
> (In reply to :Ehsan Akhgari (super long backlog, slow to respond) from
> comment #23)
> > jaruvova, firstly, *please* stop needinfo-ing random people and linking this
> > bug to random bugs.  This doesn't come across as very respectful and will
> > eventually cause people to end up ignoring you, which I think isn't your
> > intention.  Clearly you are seeing a bug that you are very passionate about.
> > I tried going to http://imgur.com/gallery/BE5iT to try to reproduce myself
> > without any luck.  That may suggest that there is something that causes the
> > bug happen for you but not for me, so you can help us figure out what broke
> > it.
> > 
> > There is a tool called mozregression that allows you to find a regression
> > range that basically tells us what code change first broke something for
> > you.  You can find it plus documentation at
> > http://mozilla.github.io/mozregression/.  Are you willing to run it to help
> > us find out what caused the change you are seeing?  A command like
> > |mozregression --good 50 --bad 55| will start a regression detection between
> > Firefox 50 and 55, but you may want to try to run mozregression --launch
> > 51/52/etc to try out more recent versions first to find a narrower
> > regression range.  It may be easier to do this if you start from a narrower
> > regression range.
> > 
> > Thank you!
> 
> 
> Ah sorry new here though need info was the right way.
> 
> Yes willing to help that why created an account and filed a bug.
> 
> Mozreg seems a bit too much for noob like me but willing to try.
> what should i look for with respect to this bug?

Mozregression launches a firefox window, then you try to reproduce the bug (in this case, going to the URL, and trying your STR), and depending of the result you write down the result, and mozregression finds another suitable build to test.

You can read more at http://mozilla.github.io/mozregression/quickstart.html, and install it at http://mozilla.github.io/mozregression/install.html.

> How  do i know what am i looking for?

You should open the browser, and see if the bug reproduces. Depending on whether it does or not, mozregression will narrow the regression window (for example, if it reproduces in 53 but not in 52, it'll start looking at changes between those two releases, and so on. When you get to a narrow-enough regression range, mozregression will show you a link with a list of possible changes, which you can paste here so people can analyze it and determine what happens.

> can you please tell which version was e10s initially released ?

I think 48, though I'm talking from memory, so I could be wrong.

Thanks again! :)
Flags: needinfo?(ehsan)
(In reply to Timothy Nikkel (:tnikkel) from comment #20)
> In the e10s video are you doing anything besides clicking on the "load more"
> button? A screencap with the page scrollbar would help to tell what is going
> on. If you aren't doing anything else then that doesn't look like what I
> would expect. Does the same thing happen with addons disabled or safe mode
> or a fresh profile?

Uploading the one's you asked.
Attached video e10s on Fx52.mp4
Attached video e10 on Fx55.mp4
Attached video Fx 55 with e10s off.mp4 (obsolete) —
It's not redrawing or re-flowing just butter smooth
with e10s off
(In reply to Emilio Cobos Álvarez [:emilio] from comment #25)
> (In reply to jaruvova from comment #24)
> > (In reply to :Ehsan Akhgari (super long backlog, slow to respond) from
> > comment #23)
> > > jaruvova, firstly, *please* stop needinfo-ing random people and linking this
> > > bug to random bugs.  This doesn't come across as very respectful and will
> > > eventually cause people to end up ignoring you, which I think isn't your
> > > intention.  Clearly you are seeing a bug that you are very passionate about.
> > > I tried going to http://imgur.com/gallery/BE5iT to try to reproduce myself
> > > without any luck.  That may suggest that there is something that causes the
> > > bug happen for you but not for me, so you can help us figure out what broke
> > > it.
> > > 
> > > There is a tool called mozregression that allows you to find a regression
> > > range that basically tells us what code change first broke something for
> > > you.  You can find it plus documentation at
> > > http://mozilla.github.io/mozregression/.  Are you willing to run it to help
> > > us find out what caused the change you are seeing?  A command like
> > > |mozregression --good 50 --bad 55| will start a regression detection between
> > > Firefox 50 and 55, but you may want to try to run mozregression --launch
> > > 51/52/etc to try out more recent versions first to find a narrower
> > > regression range.  It may be easier to do this if you start from a narrower
> > > regression range.
> > > 
> > > Thank you!
> > 
> > 
> > Ah sorry new here though need info was the right way.
> > 
> > Yes willing to help that why created an account and filed a bug.
> > 
> > Mozreg seems a bit too much for noob like me but willing to try.
> > what should i look for with respect to this bug?
> 
> Mozregression launches a firefox window, then you try to reproduce the bug
> (in this case, going to the URL, and trying your STR), and depending of the
> result you write down the result, and mozregression finds another suitable
> build to test.
> 
> You can read more at http://mozilla.github.io/mozregression/quickstart.html,
> and install it at http://mozilla.github.io/mozregression/install.html.
> 
> > How  do i know what am i looking for?
> 
> You should open the browser, and see if the bug reproduces. Depending on
> whether it does or not, mozregression will narrow the regression window (for
> example, if it reproduces in 53 but not in 52, it'll start looking at
> changes between those two releases, and so on. When you get to a
> narrow-enough regression range, mozregression will show you a link with a
> list of possible changes, which you can paste here so people can analyze it
> and determine what happens.
> 
> > can you please tell which version was e10s initially released ?
> 
> I think 48, though I'm talking from memory, so I could be wrong.
> 
> Thanks again! :)

Ok so this will take a lot of time,
will have to find time then :)
so will try to run it and post links.

Till then hope the screencasts help you guys to solve this.

Sorry to everyone including eshan.
Thank you emilio (btw way if i run into any issues how can i ask for help?)

Thanks everyone.
I think if you use mozregression, the builds that it downloads will run e10s by default at all times, so you will be good on that!

If you face any difficulties please feel free to ask a question right here.  Either myself or someone else who is already CCed would be happy to help you.  If you required real time help from someone, please feel free to join our IRC network: https://wiki.mozilla.org/IRC.  There are many channels, but a lot of us hang out on #developers.  You're always welcome to drop by and ask for help.  :-)

I'm afraid the screencasts on their own won't be of much help to us, but we're really interested on these types of performance bug reports on real user's computers especially because we can't always reproduce these problems ourselves, so we'd really appreciate it if you could find the time to try out mozregression.  And if you didn't, that's OK too, we still appreciate you taking the time to report the bug so far, perhaps someone else manages to reproduce the bug or find out more information that eventually leads to a diagnosis.

Thanks again and have a great day!
(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #31)
> I think if you use mozregression, the builds that it downloads will run e10s
> by default at all times, so you will be good on that!
> 
> If you face any difficulties please feel free to ask a question right here. 
> Either myself or someone else who is already CCed would be happy to help
> you.  If you required real time help from someone, please feel free to join
> our IRC network: https://wiki.mozilla.org/IRC.  There are many channels, but
> a lot of us hang out on #developers.  You're always welcome to drop by and
> ask for help.  :-)
> 
> I'm afraid the screencasts on their own won't be of much help to us, but
> we're really interested on these types of performance bug reports on real
> user's computers especially because we can't always reproduce these problems
> ourselves, so we'd really appreciate it if you could find the time to try
> out mozregression.  And if you didn't, that's OK too, we still appreciate
> you taking the time to report the bug so far, perhaps someone else manages
> to reproduce the bug or find out more information that eventually leads to a
> diagnosis.
> 
> Thanks again and have a great day!


Thank you will surely try to find via mozreg,
don't know much about irc but will contact you guys if need arises.
Started build 48 downloading,
Just one more bit do i need a new profile?

Thank you guys once again, have a good day :)
Actually can you please try one last thing?  This one will take a couple of minutes only.

In Firefox 55 with e10s on, please go to https://perf-html.io/, click on "new version of the Gecko Profiler add-on", click Allow, then Add, then the Gecko Profiler extension should get installed for you and install a blue icon on your toolbar.  Then please go to the imgur gallery and reproduce the issue.  After scrolling a big, click on the blue icon, and select Capture Profile.  This opens up a new tab that shows a "profile" on what Firefox was doing, which basically shows detailed information of what was going on internally that will allow people like me to figure out why things are slow.

Here you can click on Share to upload this data (please note that this will upload some private information from the tabs that you had open such as the URLs of the open tabs).  Once the upload is finished, you can copy and paste the short link here and we can have a look at it to see if we can decipher what is going on...
(In reply to jaruvova from comment #32)
> Just one more bit do i need a new profile?

I suggest using a new profile for all testing, but if you use mozregression it takes care of creating new profiles, downloading builds and everything for you.  The command I mentioned before is really the only command you have to type!
(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #34)
> (In reply to jaruvova from comment #32)
> > Just one more bit do i need a new profile?
> 
> I suggest using a new profile for all testing, but if you use mozregression
> it takes care of creating new profiles, downloading builds and everything
> for you.  The command I mentioned before is really the only command you have
> to type!

i used the gui version with fx48 as starting point and it also has the bug, if fx48 introduced e10s then does it mean the flaw was there from the beginning?
Fx44/43/42/41 also have the same issues(none with e10s off)

Can anyone tell me which version introduced e10s for the first time?

Or maybe e10s from the start has this problem?
(In reply to jaruvova from comment #29)
> Created attachment 8865720 [details]
> Fx 55 with e10s off.mp4
> 
> It's not redrawing or re-flowing just butter smooth
> with e10s off

I'm still confused about exactly what steps you are using to reproduce this bug. After you click the "load more" button why does the page scroll to the top? It doesn't for me. Are you causing the page to scroll before the extra images are loaded?
(In reply to Timothy Nikkel (:tnikkel) from comment #41)
> (In reply to jaruvova from comment #29)
> > Created attachment 8865720 [details]
> > Fx 55 with e10s off.mp4
> > 
> > It's not redrawing or re-flowing just butter smooth
> > with e10s off
> 
> I'm still confused about exactly what steps you are using to reproduce this
> bug. After you click the "load more" button why does the page scroll to the
> top? It doesn't for me. Are you causing the page to scroll before the extra
> images are loaded?

yes as soon as click load more scroll to the top,
The 1st image which is already loaded is loaded again(if it was cached it would draw instantly instead of loading progressively )

Using mozreg to find window of bug as ehsan said but still no luck
Flags: needinfo?(tnikkel)
Attached video fx36.mp4
Fx36 also has problem see the screencast :(
I don't see the difference in behaviour between your "e10 on Fx55.mp4" and "Fx 55 with e10s off.mp4" attachments. Can you explain what is good about the one with e10s off and what is bad about the one with e10s on?
Flags: needinfo?(tnikkel)
(In reply to jaruvova from comment #42)
> (In reply to Timothy Nikkel (:tnikkel) from comment #41)
> > (In reply to jaruvova from comment #29)
> > > Created attachment 8865720 [details]
> > > Fx 55 with e10s off.mp4
> > > 
> > > It's not redrawing or re-flowing just butter smooth
> > > with e10s off
> > 
> > I'm still confused about exactly what steps you are using to reproduce this
> > bug. After you click the "load more" button why does the page scroll to the
> > top? It doesn't for me. Are you causing the page to scroll before the extra
> > images are loaded?
> 
> yes as soon as click load more scroll to the top,
> The 1st image which is already loaded is loaded again(if it was cached it
> would draw instantly instead of loading progressively )
> 
> Using mozreg to find window of bug as ehsan said but still no luck

also scrolling up to show the problem ie the images reload from start, just use scroll wheel to scroll up fast
even if they were properly loaded before
(look at the first picture it loads fine but after clicking load more it starts reloading)

all images reload after clicking load more which is the problem as they should not reload as they are already in cache,
e10s off does not do that and only loads new images and old ones(like the 1st picture stay intact)
that's why said bug 1361388 also might be related to this as it also causes jank and flickering.

well Fx36 also has this problem with e10s, any idea which version initially introduced e10s as if it's after 48 then FX36 also has e10s(mozreg like ehsan said) so should test more builds?

Also just to clear thing posting with Fx55 e10s off just to show.
In your attachment "Fx 55 with e10s off.mp4" I see the first image is not drawn, and then it is drawn after half a second. So how is that different from your other attachments?
Attachment #8865720 - Attachment is obsolete: true
Attached video fx55 with e10s off.mp4
Notice the first image and the images below it are not reloaded from server or redrawn as scrolling down and is displayed as they should without any issues.
can you guys help a bit here,Fx36 is the version which i tested starting from Fx50,
If you could provide the initial build in which e10s landed then could test on it and see.if from the start this problem was there or not.

Also tested on 3laptops with different configurations so it's not HW related.
This issue is stopping most of my acquaintances from switching on e10s, (we all do graphics related works so)


Sorry but needinfoing you guys just to know if should wait for the initial build info or any other ideas,
Flags: needinfo?(tnikkel)
Flags: needinfo?(ehsan)
In my case, I can reproduce the issue with e10 disabled and enabled, which is redownloading/reloading/redrawing images after pressing "Load XXX more images" button and instantly going to top, but I suspect it has something to do with discarding images from memory, so it could be "no issue".
Severity: critical → normal
Has Regression Range: --- → no
Component: Untriaged → Graphics
Keywords: multiprocess
Product: Firefox → Core
Version: 55 Branch → unspecified
(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #33)
> Actually can you please try one last thing?  This one will take a couple of
> minutes only.
> 
> In Firefox 55 with e10s on, please go to https://perf-html.io/, click on
> "new version of the Gecko Profiler add-on", click Allow, then Add, then the
> Gecko Profiler extension should get installed for you and install a blue
> icon on your toolbar.  Then please go to the imgur gallery and reproduce the
> issue.  After scrolling a big, click on the blue icon, and select Capture
> Profile.  This opens up a new tab that shows a "profile" on what Firefox was
> doing, which basically shows detailed information of what was going on
> internally that will allow people like me to figure out why things are slow.
> 
> Here you can click on Share to upload this data (please note that this will
> upload some private information from the tabs that you had open such as the
> URLs of the open tabs).  Once the upload is finished, you can copy and paste
> the short link here and we can have a look at it to see if we can decipher
> what is going on...

sorry had missed the comment

https://perfht.ml/2pWGc4F 1st run

https://perfht.ml/2pX2HXp 2nd run

https://perfht.ml/2pX5ksf e10s disabled

is there any way you could see my screen?
then could show but screen cast is too big to share.
Severity: normal → critical
Has Regression Range: no → ---
Component: ImageLib → Untriaged
Keywords: multiprocess
Product: Core → Firefox
Version: unspecified → 55 Branch
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #49)
> In my case, I can reproduce the issue with e10 disabled and enabled, which
> is redownloading/reloading/redrawing images after pressing "Load XXX more
> images" button and instantly going to top, but I suspect it has something to
> do with discarding images from memory, so it could be "no issue".

oops again mid-air collision or something :(

http://imgur.com/gallery/De0HZ

once the page is loaded click more wait for all images to load.
Refresh the page , click more again.

with e10s off images load instantly(no reloading)
no cpu spikes or network usage.

with e10s on all images start reloading(even the ones cached before the refresh)
cpu spikes and networx shows activity
Flags: needinfo?(Virtual)
Severity: critical → normal
Has Regression Range: --- → no
Component: Untriaged → ImageLib
Keywords: multiprocess
Product: Firefox → Core
Version: 55 Branch → unspecified
Another STR:

E10s on

visit the page,
click load more and let it load,
open the url in new tab or reload using reload button,

IMAGES are again loaded from server!
Bypassing cache totally,

now turn off e10s restart,
do the same thing,
IMAGES and page loads instantly if using reload button or url in new tab
No reloading from server,

So might this be a cache issue?
I can't confirm e10s enabled vs e10s disabled issue in my case.
I tried Firefox [Portable]:
- 45 (Legacy)
- 52 (ESR)
- 53 (Stable)
- 54 (Beta)
- 55 (Nightly).
But it could be that I have too fast ISP to catch it now. I will try later with limiting browser bandwidth.

About not forced reloading page with redownloading all content, some pages make browser look again for image instead of retrieving the one in cache, so it's could be website specific "feature".
Flags: needinfo?(Virtual)
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #53)
> I can't confirm e10s enabled vs e10s disabled issue in my case.
> I tried Firefox [Portable]:
> - 45 (Legacy)
> - 52 (ESR)
> - 53 (Stable)
> - 54 (Beta)
> - 55 (Nightly).
> But it could be that I have too fast ISP to catch it now. I will try later
> with limiting browser bandwidth.
> 
> About not forced reloading page with redownloading all content, some pages
> make browser look again for image instead of retrieving the one in cache, so
> it's could be website specific "feature".

Portable version might not show


try installing

can reproduce always

watch the attachments to see what i mean
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #53)
> - 45 (Legacy)
> - 52 (ESR)
> - 53 (Stable)
> - 54 (Beta)
> - 55 (Nightly).

can reproduce with all of the with e10s on & work fine with off

> But it could be that I have too fast ISP to catch it now. I will try later
> with limiting browser bandwidth.

please do, also monitor network usage too.
Flags: needinfo?(Virtual)
(In reply to jaruvova from comment #54)
> (In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see
> your comment/reply/question/etc.) from comment #53)


> > About not forced reloading page with redownloading all content, some pages
> > make browser look again for image instead of retrieving the one in cache, so
> > it's could be website specific "feature".
> 
No it's not a feature if it works on
non e10s/chrome/EDGE
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #53)
> I can't confirm e10s enabled vs e10s disabled issue in my case.
> I tried Firefox [Portable]:
> - 45 (Legacy)
> - 52 (ESR)
> - 53 (Stable)
> - 54 (Beta)
> - 55 (Nightly).

Just downloaded all the above you mentioned and tested.
No wonder you could not reproduce as they have hard-coded some stuff,
& to prevent fingerprinting have disabled lots of things hence always loaded from server


Downloaded 5.2gb worth of builds and tested and still no info why this is happening :(
Attached video EDGE.mp4
In EDGE it so smooth with hardly any jerk or redraws,
cpu usage is very low 5% as it is fully GPU accelerated
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0 (e10s on)

Watching the network traffic in the inspector the first time I load the page (http://imgur.com/gallery/BE5iT), upon clicking the "Load 11 More Images" button and scrolling up, I see Firefox downloading the files again (HTTP GET, HTTP/200). However, it looks like it is receiving different images with the same name and images but different file sizes and smaller dimensions. If I reload the page after that, everything is HTTP/304 Not Modified and served from cache. I am not seeing the same behavior on Chrome, it is the smaller file from the beginning (728x410).

For the second image, for example, I receive this response on the first GET for FPOenIQ.jpg (1600x900 resolution):

Last-Modified: Tue, 04 Jun 2013 12:31:27 GMT
Etag: "5fe056f3db49e153493cf13a43492eee"
x-amz-storage-class: STANDARD_IA
Content-Type: image/jpeg
fastly-debug-digest: 8de514c4f2550796af7a302695926920fb93b514e03112e79da9c72c429e537a
Cache-Control: public, max-age=31536000
Content-Length: 307680
Accept-Ranges: bytes
Date: Tue, 09 May 2017 17:32:56 GMT
Age: 1485843
Connection: keep-alive
x-served-by: cache-iad2127-IAD, cache-sea1032-SEA
X-Cache: HIT, HIT
x-cache-hits: 1, 2
x-timer: S1494351176.484488,VS0,VE0
Vary: Accept
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Origin: *
Server: cat factory 1.0

This for the second GET just by scrolling up (resolution 728x410) :

Last-Modified: Thu, 04 May 2017 11:55:52 GMT
x-amz-expiration: expiry-date="Fri, 12 May 2017 00:00:00 GMT", rule-id="Expire Thumbnails"
Etag: "1f8a0ab59e0f172711c0fde11b5612ee"
Content-Type: image/jpeg
fastly-debug-digest: 27a59cdf44cce8fd950f40db36e04adc12f8f07786fa3f10bdddec18a913c0af
Cache-Control: public, max-age=31536000
Content-Length: 74869
Accept-Ranges: bytes
Date: Tue, 09 May 2017 17:33:15 GMT
Age: 284192
Connection: keep-alive
x-served-by: cache-iad2142-IAD, cache-sea1028-SEA
X-Cache: HIT, HIT
x-cache-hits: 2, 1
x-timer: S1494351195.173353,VS0,VE2
Vary: Accept, Accept
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Origin: *
Server: cat factory 1.0
Unlike the original report, however, I am also seeing this behavior in ESR 45.9 with e10s disabled (obvious reloading of the images with network inspector showing a smaller image loaded the second time).
(In reply to Steven S. from comment #60)
> Unlike the original report, however, I am also seeing this behavior in ESR
> 45.9 with e10s disabled (obvious reloading of the images with network
> inspector showing a smaller image loaded the second time).

well it might be that it's more apparent in e10s.

Can you please check this on EDGE too and see if you get the same problem since it does not reload or redraw while clicking load more,
also look at the EDGE attachment and the scrolling with images being displayed, do you get similar with Fx45?
Flags: needinfo?(steven)
When I do this in Edge it does appear to reload the images, but may have completed doing so before I am able scroll up, or it may ignore some logic in the page that delays loading until an image is visible (or perhaps loads groups of images).

In Edge, the initial image was 1456x819 and 258.62KB, when I scroll up it loads one that is 728x410 and 73.11KB. If I click it to zoom in it loads the full 1600x900. Refreshing the page loads the small one from the cache.

In Chrome it will load the full 1600x900 when I click the image to zoom.


I think there may be an issue with their thumbnail/full-size logic on the page.
Flags: needinfo?(steven)
Whiteboard: [gfx-noted]
(In reply to Steven S. from comment #62)
> When I do this in Edge it does appear to reload the images, but may have
> completed doing so before I am able scroll up, or it may ignore some logic
> in the page that delays loading until an image is visible (or perhaps loads
> groups of images).
> 
> In Edge, the initial image was 1456x819 and 258.62KB, when I scroll up it
> loads one that is 728x410 and 73.11KB. If I click it to zoom in it loads the
> full 1600x900. Refreshing the page loads the small one from the cache.
> 
> In Chrome it will load the full 1600x900 when I click the image to zoom.
> 
> 
> I think there may be an issue with their thumbnail/full-size logic on the
> page.

Thanks for the info steven,
not arguing that the page might be at fault but what cause the issue in e10s vs non e10s is that worrying.
bug 1361388 has similar issues with different pages with images.

but still the redrawing and repainting? should not happen in e10s just like none10s /EDGE/Chrome.
It's smoother in them compared to little flickering in e10s.

maybe ehsan can look into the asked profiler info and find something that causing this.
Unfortunately none of the profiles you submitted include symbolified stacks (which could be due to a bug somewhere, I'm not really sure) so they're not entirely descriptive and they don't reveal as much information as I was hoping.  One thing that they do show in the e10s case is that the main thread of the parent process is mostly idle and while the main thread of the content process is doing a lot of work, it is managing to pain quite frequently, which is desirable when you are scrolling a web page like this.  IOW, the behavior you're seeing isn't due to some expensive computation happening somewhere, so at least it rules out some possibilities...
Flags: needinfo?(ehsan)
Successfully compiled asm.js code (loaded from cache in 4409ms)
zee-worker.js
Error: Unable to connect to the Gecko profiler add-on within thirty seconds.
Stack trace:
e/</<@https://perf-html.io/77f3188de8004b708832.bundle.js:30:6819
77f3188de8004b708832.bundle.js:33:6589
value
https://perf-html.io/77f3188de8004b708832.bundle.js:33:6589
_renderValidatedComponentWithoutOwnerOrContext
https://perf-html.io/77f3188de8004b708832.bundle.js:37:23148
_renderValidatedComponent
https://perf-html.io/77f3188de8004b708832.bundle.js:37:23272
_updateRenderedComponent
https://perf-html.io/77f3188de8004b708832.bundle.js:37:22572
_performComponentUpdate
https://perf-html.io/77f3188de8004b708832.bundle.js:37:22373
updateComponent
https://perf-html.io/77f3188de8004b708832.bundle.js:37:21651
receiveComponent
https://perf-html.io/77f3188de8004b708832.bundle.js:37:20762
receiveComponent
https://perf-html.io/77f3188de8004b708832.bundle.js:12:13075
_updateRenderedComponent
https://perf-html.io/77f3188de8004b708832.bundle.js:37:22619
_performComponentUpdate
https://perf-html.io/77f3188de8004b708832.bundle.js:37:22373
updateComponent
https://perf-html.io/77f3188de8004b708832.bundle.js:37:21651
performUpdateIfNecessary
https://perf-html.io/77f3188de8004b708832.bundle.js:37:20978
performUpdateIfNecessary
https://perf-html.io/77f3188de8004b708832.bundle.js:12:13257
s
https://perf-html.io/77f3188de8004b708832.bundle.js:12:1198
perform
https://perf-html.io/77f3188de8004b708832.bundle.js:12:31496
perform
https://perf-html.io/77f3188de8004b708832.bundle.js:12:31496
perform
https://perf-html.io/77f3188de8004b708832.bundle.js:12:2259
k
https://perf-html.io/77f3188de8004b708832.bundle.js:12:2436
closeAll
https://perf-html.io/77f3188de8004b708832.bundle.js:13:65
perform
https://perf-html.io/77f3188de8004b708832.bundle.js:12:31576
batchedUpdates
https://perf-html.io/77f3188de8004b708832.bundle.js:38:15210
u
https://perf-html.io/77f3188de8004b708832.bundle.js:12:1480
r
https://perf-html.io/77f3188de8004b708832.bundle.js:13:29150
enqueueSetState
https://perf-html.io/77f3188de8004b708832.bundle.js:13:30152
r.prototype.setState
https://perf-html.io/77f3188de8004b708832.bundle.js:27:1055
l/</r</s.prototype.handleChange
https://perf-html.io/77f3188de8004b708832.bundle.js:39:14405
d
https://perf-html.io/77f3188de8004b708832.bundle.js:29:20587
r/</</<
https://perf-html.io/77f3188de8004b708832.bundle.js:29:31252
r/</</<
https://perf-html.io/77f3188de8004b708832.bundle.js:40:10860
dispatch
https://perf-html.io/77f3188de8004b708832.bundle.js:40:11165
t/<
https://perf-html.io/77f3188de8004b708832.bundle.js:30:3456
r
https://perf-html.io/77f3188de8004b708832.bundle.js:40:14175
l/<
https://perf-html.io/77f3188de8004b708832.bundle.js:40:15604
s/</e[t]
https://perf-html.io/77f3188de8004b708832.bundle.js:40:14351
r
https://perf-html.io/77f3188de8004b708832.bundle.js:28:20510
r/<
https://perf-html.io/77f3188de8004b708832.bundle.js:28:20641
i
https://perf-html.io/77f3188de8004b708832.bundle.js:34:31886
R/<
https://perf-html.io/77f3188de8004b708832.bundle.js:34:32008
l
https://perf-html.io/77f3188de8004b708832.bundle.js:34:26209
Unhandled promise rejection Error: Unable to connect to the Gecko profiler add-on within thirty seconds.
Stack trace:
e/</<@https://perf-html.io/77f3188de8004b708832.bundle.js:30:6819
77f3188de8004b708832.bundle.js:35:222
M/</t<
https://perf-html.io/77f3188de8004b708832.bundle.js:35:222
O
https://perf-html.io/77f3188de8004b708832.bundle.js:34:31636
M/<
https://perf-html.io/77f3188de8004b708832.bundle.js:35:99
e.exports
https://perf-html.io/77f3188de8004b708832.bundle.js:34:25239
<anonymous>
https://perf-html.io/77f3188de8004b708832.bundle.js:28:24879
y
https://perf-html.io/77f3188de8004b708832.bundle.js:28:24737
b
https://perf-html.io/77f3188de8004b708832.bundle.js:28:24757


getting these errors so maybe that;s why it;s missing stuff?

fresh copy btw
(In reply to jaruvova from comment #55)
> (In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see
> your comment/reply/question/etc.) from comment #53)
> > - 45 (Legacy)
> > - 52 (ESR)
> > - 53 (Stable)
> > - 54 (Beta)
> > - 55 (Nightly).
> 
> can reproduce with all of the with e10s on & work fine with off
> 
> > But it could be that I have too fast ISP to catch it now. I will try later
> > with limiting browser bandwidth.
> 
> please do, also monitor network usage too.

I can't reproduce the issues what you're seeing, even with limiting network speed.



(In reply to jaruvova from comment #57)
> (In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see
> your comment/reply/question/etc.) from comment #53)
> > I can't confirm e10s enabled vs e10s disabled issue in my case.
> > I tried Firefox [Portable]:
> > - 45 (Legacy)
> > - 52 (ESR)
> > - 53 (Stable)
> > - 54 (Beta)
> > - 55 (Nightly).
> 
> Just downloaded all the above you mentioned and tested.
> No wonder you could not reproduce as they have hard-coded some stuff,
> & to prevent fingerprinting have disabled lots of things hence always loaded
> from server
> 
> 
> Downloaded 5.2gb worth of builds and tested and still no info why this is
> happening :(

I don't know from where you downloaded these builds, but mine just don't write anything to operating system and don't collide with installed Firefox. Settings, preferences and options are the same like in normal Firefox builds, nothing is changed.
Flags: needinfo?(Virtual)
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #66)
> (In reply to jaruvova from comment #55)
> > (In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see
> > your comment/reply/question/etc.) from comment #53)
> > > - 45 (Legacy)
> > > - 52 (ESR)
> > > - 53 (Stable)
> > > - 54 (Beta)
> > > - 55 (Nightly).
> > 
> > can reproduce with all of the with e10s on & work fine with off
> > 
> > > But it could be that I have too fast ISP to catch it now. I will try later
> > > with limiting browser bandwidth.
> > 
> > please do, also monitor network usage too.
> 
> I can't reproduce the issues what you're seeing, even with limiting network
> speed.
> 
> 
> 
> (In reply to jaruvova from comment #57)
> > (In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see
> > your comment/reply/question/etc.) from comment #53)
> > > I can't confirm e10s enabled vs e10s disabled issue in my case.
> > > I tried Firefox [Portable]:
> > > - 45 (Legacy)
> > > - 52 (ESR)
> > > - 53 (Stable)
> > > - 54 (Beta)
> > > - 55 (Nightly).
> > 
> > Just downloaded all the above you mentioned and tested.
> > No wonder you could not reproduce as they have hard-coded some stuff,
> > & to prevent fingerprinting have disabled lots of things hence always loaded
> > from server
> > 
> > 
> > Downloaded 5.2gb worth of builds and tested and still no info why this is
> > happening :(
> 
> I don't know from where you downloaded these builds, but mine just don't
> write anything to operating system and don't collide with installed Firefox.
> Settings, preferences and options are the same like in normal Firefox
> builds, nothing is changed.

Just read their documentation and see, won't argue on it,
you won't be able to produce by default on those builds as they will *always* load from server negating the issue here.
(In reply to jaruvova from comment #67)
> Just read their documentation and see, won't argue on it,
> you won't be able to produce by default on those builds as they will
> *always* load from server negating the issue here.

I created them by myself, so there is nothing more to read, except Mozilla documentation. ;)
You're talking probably about other portable builds, which are available on internet like PortableApps.com, but even looking on these builds, only change is disabled disk cache.
But even when I use latest Nightly which I installed, I can't reproduce the issues what you're seeing, even with limiting network.
(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #64)
> Unfortunately none of the profiles you submitted include symbolified stacks
> (which could be due to a bug somewhere, I'm not really sure) so they're not
> entirely descriptive and they don't reveal as much information as I was
> hoping.  One thing that they do show in the e10s case is that the main
> thread of the parent process is mostly idle and while the main thread of the
> content process is doing a lot of work, it is managing to pain quite
> frequently, which is desirable when you are scrolling a web page like this. 
> IOW, the behavior you're seeing isn't due to some expensive computation
> happening somewhere, so at least it rules out some possibilities...

Tested till Fx33 but still the problem persists.

also

image.mem.surfacecache.discard_factor

image.decode-immediately.enabled

helps to improve it(the redrawing occurs less)
Guys can you test one more thing ,

new profile e10s on

load 8-10 images in tabs, only images like https://i.redd.it/l0bmvng2gmxy.jpg and not with pages.

now close them one by one using keyboard, image flick while showing, edge etc its smooth.

now on non e10s windows do the same and the image does not flicker .

It's related to this bug as just like the op i have the exact same issue as described in this bug.
Asked various forum users and most of them have the issue.

This is a critical bug as perceived performance looks slow and that flicker make it look like firefox is hogging resources
P.S: how to record firefox windows in a gif or mp4 to show?
Flags: needinfo?(ehsan)
I'm sorry, I don't have anything to add here besides what I have said previously.
Flags: needinfo?(ehsan)
(In reply to jigsawmode from comment #70)
> ...
> P.S: how to record firefox windows in a gif or mp4 to show?

That's a question without a quick answer, but https://en.wikipedia.org/wiki/Comparison_of_screencasting_software covers a good set of options.
Severity: normal → S3
Flags: needinfo?(tnikkel)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: