STR: Visit http://frozenbyte.com/ (VG studio) Result: Firefox process (in process manager of Win 7) shows 30% of CPU use. Setting image.high_quality_downscaling.enabled=false fixes the issue (~0%). Regression range good=2012-10-17 bad=2012-10-18 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dac5700acf8b&tochange=cb573b9307e5 Suspected bug 795940. With the build of 2012-10-18, the CPU use is ~15-18%. With the latest Nightly, it's more ~30%. So I think the issue has been amplified with some new patches about image high-quality downscaling since this feature has landed in Firefox 19.
It looks like there is a 2nd regression range, increasing the CPU use from 20% to ~30% http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4dfe323a663d&tochange=634180132e68
#1 Regression window (force setting image.high_quality_downscaling.enabled=true ) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/1dde5624fc81 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120929210240 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/aaf9e3020132 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120929220017 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1dde5624fc81&tochange=aaf9e3020132 #1 Regressed by: Bug 486918 #2 Regression window: Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/89ad76a08a74 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121211 Firefox/20.0 ID:20121211125858 More Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/9602f98a6a70 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121211 Firefox/20.0 ID:20121211143159 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=89ad76a08a74&tochange=9602f98a6a70 In local build: Bad: 9dffd2d825c9 More bad: 513ec84b5c88 #2 Regressed by: 513ec84b5c88 Vladimir Vukicevic — b=731974, requestAnimationFrame generates too short/long frames (incl. bug 799242); r=bz,smaug,roc,ehsan I've filed a Bug 927507 for the #2Regression
Jeff, let's talk about what we should do here and in bug 927507.
Does this still happen? We fixed the main bug that caused high quality downscaling to use too much cpu.
(In reply to Timothy Nikkel (:tn) from comment #5) > Does this still happen? We fixed the main bug that caused high quality > downscaling to use too much cpu. Loic, Alice: are you still able to reproduce?
WFM on Nightly44.0a3
Thank you for the update, Alice. I will close this bug accordingly. Loic, please reopen if you still have problems in current Firefox versions.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
WFM with Nightly
So high quality scaling code has been removed from nightly (in favour of downscale during decode), so that makes sense.
(In reply to Timothy Nikkel (:tn) from comment #11) > So high quality scaling code has been removed from nightly (in favour of > downscale during decode), so that makes sense. Oh... so the problem may still be present, but hidden. tn: is there a way for Alice and Loic to test with high-quality downscaling enabled?
(In reply to Nicholas Nethercote [:njn] from comment #12) > Oh... so the problem may still be present, but hidden. tn: is there a way > for Alice and Loic to test with high-quality downscaling enabled? On short: no, the C++ code has been removed from the tree. Downscale during decode (done properly) should makes HQ downscaling completely obsolete. Downscale during decode is designed differently from the HQ downscaler. The HQ downscaler decoded the image at the default size, and then downscaled it (with support for exactly one size of HQ scaled frame at a time). Downscale during decode decodes a version of the image for the requested size. And the necessary smarts to deal with having more than one size of the same image has been added. The HQ downscaler didn't have these smarts, it was more of a hack on top of the existing infrastructure. So while the same problem could theoretically exist, the new framework was specifically designed to avoid the same kinds of problems.
Great! Thank you for clarifying.
You need to log in before you can comment on or make changes to this bug.