Huge CPU use on http://frozenbyte.com/ with image high-quality downscaling enabled

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
6 years ago
4 years ago

People

(Reporter: epinal99-bugzilla2, Unassigned)

Tracking

({perf, power, regression})

18 Branch
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox24 affected, firefox25 affected, firefox26 affected, firefox27 affected, firefox28 affected, firefox29 affected, firefox-esr24 affected)

Details

(Whiteboard: [Power])

Attachments

(1 attachment)

32.62 KB, application/x-zip-compressed
Details
Reporter

Description

6 years ago
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.
Reporter

Updated

6 years ago
Blocks: 795940
Keywords: regression
Reporter

Comment 1

6 years ago
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

Updated

6 years ago
Version: 19 Branch → 18 Branch

Comment 3

6 years ago
#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
Blocks: 486918
No longer blocks: 795940
Jeff, let's talk about what we should do here and in bug 927507.
Flags: needinfo?(jmuizelaar)
Whiteboard: [Power]
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?
Flags: needinfo?(epinal99-bugzilla2)
Flags: needinfo?(alice0775)

Comment 7

4 years ago
WFM on Nightly44.0a3
Flags: needinfo?(alice0775)

Comment 8

4 years ago
oops 44.0a1
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
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(epinal99-bugzilla2)
Resolution: --- → WORKSFORME
Reporter

Comment 10

4 years ago
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?
Flags: needinfo?(tnikkel)
(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.
Flags: needinfo?(tnikkel)
Great! Thank you for clarifying.
You need to log in before you can comment on or make changes to this bug.