>>> My Info: Win7_64, Nightly 46, 32bit, ID 20160126030244 STR: 1. Save attached "testcase 1", open .htm file in firefox. I discovered the bug while using Tumblr 2. Click on the page 3.A) As fast as possible {press button that produces 'keyup'} (x4 times) I do it like this: successively press keys "d", "k", "d", "k" in ~1 second 3.B) For 5 seconds keep pressing buttons that produce 'keyup' at the speed 2 pressings/second Result: CPU usage jumps to 80%, my cooler suffers Expectations: CPU usage should be like in the previous versions of firefox 2015-04-06 - parent process: ~5% CPU, child process: ~5% CPU [OK] 2016-01-26 - parent process: ~5% CPU, child process: ~75% CPU [affected] Note that somewhere in the middle CPU usage was: parent process: ~25% CPU, child process: ~5% CPU So I don't know exactly how reliable the regression window may be.

There are 2 regression. #1 approx.5% -> 50% #2 approx.50% -> 80% #1 regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1493e98adccf&tochange=7d7b074fc112 Regressed by: Bug 1182929 #2 regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0c777aabd5d0&tochange=03be986cf1aa Regressed by: Bug 1151359

As the images change size we decode one copy of the image for every intermediate size. There are several bugs on file for this already, but I don't have a bug number handy.

(In reply to Timothy Nikkel (:tnikkel) from comment #2) > As the images change size we decode one copy of the image for every > intermediate size. There are several bugs on file for this already, but I > don't have a bug number handy. Yeah, I can't find the bugs either, but I know they exist. What we want to do here is detect when this is happening and refuse to decode at any size except the intrinsic size until things settle down. In another bug I've posted a precise algorithm for how this should work; I'm going to try to dig it up and dupe this against that bug.

Seth, did you find these bugs mentioned above?

(In reply to Milan Sreckovic [:milan] from comment #4) > Seth, did you find these bugs mentioned above? No, but I really want to, because there was a very carefully thought out algorithm posted in there that we should just implement and use. I'll make another effort to find the bug I'm thinking of.

https://bugzilla.mozilla.org/show_bug.cgi?id=1139928#c23 is algorithm

(In reply to arni2033 from comment #0) > 2. Click on the page > 3.A) As fast as possible {press button that produces 'keyup'} (x4 times) > I do it like this: successively press keys "d", "k", "d", "k" in ~1 > second > 3.B) For 5 seconds keep pressing buttons that produce 'keyup' at the speed 2 > pressings/second We could craft a test case that forces a re-decode twice a second as these steps do, but that's not the world we're optimizing for (with downscale-during-decode.) I could be convinced otherwise with a real-world site that doesn't include rapid keyboard gymnastics to reproduce :)

(In reply to Jet Villegas (:jet) from comment #8) > We could craft a test case that forces a re-decode twice a second as these > steps do, but that's not the world we're optimizing for (with > downscale-during-decode.) I could be convinced otherwise with a real-world > site that doesn't include rapid keyboard gymnastics to reproduce :) Huh? So if a user sends some site, you demand a testcase. I provided a minimized testcase, now you demand a site? Now what's wrong?! Furthermore, you call a normal speed of sliding uninteresting pictures a "keyboard gymnastics". Each time I {switch to the next image} twice, I see this bug. "2 keypress in 1 second? EDGECASE!" I noticed that developers tend to call any bug an "edge case" and don't fix it based on this. But if there're thousands of "edge cases", you can't ignore them anymore. The whole thing gets buggy. So, let's proceed as follows: you admit you weren't completely right about "keyboard gymnastics" and me not sending porn blog to you, and I spend my time to find a SFW real-life blog with the same design

Oh, and actually I just checked in Task Manager - CPU goes to 80% for ~1-2 seconds EACH time I switch to next image. Earlier I just used a slow update speed in Task Manager, therefore the bug was only noticeable when I switched to the next image twice.

(In reply to Jet Villegas (:jet) from comment #8) > We could craft a test case that forces a re-decode twice a second as these steps do, but that's > not the world we're optimizing for (with downscale-during-decode.) So yeah, this phrase is logical failure for sure. It basically says "you reported high CPU consumption when rapidly pressing keys". That's wrong. Comment 0 only provides a way to reproduce this reliably. To keep CPU consumption at highest point. Comment 9, comment 10 prove that it happens after 1 pressing And if I make 2 pressings, I hear how cooler becomes insane. > I could be convinced otherwise with a real-world site that doesn't include rapid > keyboard gymnastics to reproduce That is just offensive. By saying "keyboard gymnastics" you say that everybody who pressed keys more often than once per second (per 5 seconds?!) is doing very strange thing. BUT, what would *you* so if you were sliding pictures and saw an image you saw before many times? Would you _immediately_ slide to the next image? I can't tell for 1985- people, but new generation would definitely do that. Another common use case is to hold Right/Left key to slide to first/last image. I just decided to make a protection from that in my testcase, because *I* do care about your CPU. > real-world site Read comment 9 about "testcases vs sites". I already told you in the summary that I encountered it on real-life Tumblr blog, and created the testcase. Do you think I'd write all that code myself only to "craft an ideal test case"? I already provided real-life example and second STR in comment 6 > ... And image https://imgur.com/DO9ASUd almost burned my CPU when I clicked on it ... and promised I'll provide similar Tumblr blog once you take back those dialectical tricks (comment 8)

Let me be clear about one thing that won't change: decoding high-resolution images takes up CPU cycles. If that's what you'd like us to fix, then we're definitely not on the same page. https://imgur.com/DO9ASUd is a 5650 x 6053 map of Europe. We can reduce CPU usage by decoding slower or at lower resolution. The laws of physics get in the way otherwise. I'm not disagreeing that your use case (NSFW or otherwise) is valid. I'm pointing out that if you want high-res images decoded at full resolution at a rapid pace, you will pay with CPU cycles. Are you disagreeing with that?

> decoding high-resolution images takes up CPU cycles. Then how came that Nightly 2015-04-06 didn't burn my CPU that much? Also,1080x1920 isn't so "high"res > If that's what you'd like us to fix, then we're definitely not on the same page. I don't want you to fix the fact that "decoding high-resolution images takes up CPU". I'd say I only want you to fix the browser to its previous state (before regressions: bug 1151359 and bug 1182929), with normal performance. It's possible since it was possible before. > Are you disagreeing with that? I said it pretty clear: first I disagreed with with calling 1 pressing per second a "rapid pace". Once we figured this,my next statement is "Firefox now spends a lot more resources for normal usecase than (at least) Chrome and than it did earlier, and therefore what caused this was a very bad change" > if you want high-res images decoded at full resolution at a rapid pace,you will pay with CPU cycles Are you trying to falsify my words? What I want as a user is to slide images at normal speed with acceptable resolution (e.g. as of 2015-04-06) and not burn my CPU. > if you want high-res images decoded at full resolution at a rapid pace,you will pay with CPU cycles > Are you disagreeing with that? It's illogical to use this arguement as you can push CPU usage up to 100% using the same reason. While the goal is to get browser to consume as few resources for the same operation as possible. Isn't this your goal? How can *you* disagree that this change (5->80) is definitely not improvement? I've found a blog, so "real-life" testing is now available > blog http://mylittlecoloruniverse.tumblr.com/ > testcase http://mylittlecoloruniverse.tumblr.com/post/142139073463/10-из-10-счастье > Archive http://web.archive.org/web/20160413210219/http://mylittlecoloruniverse.tumblr.com/post/142139073463/10-из-10-счастье

(In reply to arni2033 from comment #13) > > I've found a blog, so "real-life" testing is now available > > blog http://mylittlecoloruniverse.tumblr.com/ > > testcase http://mylittlecoloruniverse.tumblr.com/post/142139073463/10-из-10-счастье > > Archive http://web.archive.org/web/20160413210219/http://mylittlecoloruniverse.tumblr.com/post/142139073463/10-из-10-счастье Thanks! We'll review the sites you listed and look into a fix. I should note that the 2 bugs that caused this "regression" did so by improving image quality for the cases in those bugs. This one needs a closer look.

(In reply to Timothy Nikkel (:tnikkel) from comment #7) > https://bugzilla.mozilla.org/show_bug.cgi?id=1139928#c23 is algorithm Thanks, Tim. I think we can get this fixed pretty quickly now that we've found this.

Some of affected sites are listed in User Story. The 1st one is especially dangerous if it still works (In reply to Jet Villegas (:jet) from comment #14) > Thanks! We'll review the sites you listed and look into a fix. I was lucky enough that somebody took this bug + bug 1139928 seriously. It's still a bit strange that bug 1139928 was reported before this bug manifested. (BTW I haven't found a testcase in that bug) I can only add taht you probably wouldn't like to optimize for the world of _static_ images only.

Wontfix for 49. Seth or Timothy, is this something you still intend to work on (from Comment 15)?

Need info myself to find owner to work on this.

It's been there for a while, mark 50/51 as fix-optional but still happy to take the fix in 51.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1139928#c23