Closed Bug 583354 Opened 14 years ago Closed 13 years ago

-moz-background-size with flash content causes extremely high CPU usage

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -
blocking1.9.2 --- -

People

(Reporter: millerkj84, Unassigned)

Details

(Keywords: regression)

Attachments

(2 files)

small html demostrating the issue
951 bytes, text/html
Details
test case
963 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

This occurs in 3.6.4 to 3.6.8. It seemed to work fine in firefox 3.6-3.6.3

Specifying css -moz-background-size in pixels causes extremely high use of CPU by firefox. Using percents seem fine. It does not have to include flash content, but it's most noticeable on a page with flash playback.

Reproducible: Always

Steps to Reproduce:
1. Make webpage
2. Add CSS styles:
background-image: -moz-linear-gradient(top, #000000, #000088);
-moz-background-size: 1px 500px;
3. Add swf to webpage
4. Open webpage and watch firefox slow and grind at CPU
Actual Results:  
90% cpu usage on dual core 2.6ghz
60% cpu usage on quad core i5-750

Expected Results:  
20% or less cpu usage

<html>
  <style type="text/css">

  body {

    /* override background-image for newer browsers that understand CSS gradients - it looks smoother */
    background-image: -moz-linear-gradient(top, #000088, #000000);
    -moz-background-size: 1px 2000px;
    background-repeat: repeat;
    background-color: #000;
    background-position: 0 0;
    -webkit-background-size: 1px 2000px;
     }

  </style>
<div style="margin:0px; opacity:1.0;">
<object>
<param name="movie" value="http://www.youtube.com/v/JvptBXUvn0U&hl=en&fs=1&"></param>
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always"></param>
<param name="wmode" value="transparent">
<embed src="http://www.youtube.com/v/JvptBXUvn0U&hl=en&fs=1&" wmode="transparent" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="560" height="340"></embed>
</object>
</div>
</body>
</html>
Make a .html file. Use the above text as the code. Save the file. Open it in firefox 3.6.8
**Warning, opening this may cause firefox to become unresponsive while the video is playing, especially on a single core machine. 

You can open firebug and turn on/off the moz-background-size and see the performance changes immediately.


Also, this is in Firefox 3.6.4-3.6.8. I have not tried in Firefox 4 but this file would not demonstrate the issue since the CSS tag changed(background-size I think).
The latest Minefield nightly (20100730) also show quite a high cpu usage (~95%) on an edited file.
On this machine, playing a Youtube movie normally accounts for 40~50% CPU
Attached file test case — 
test case that works on both Gecko 1.9.2 (fx 3.6.8) and Gecko 2.0. -moz-background-size --> background-size.
Status: UNCONFIRMED → NEW
Component: General → Graphics
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → thebes
blocking1.9.2: --- → ?
blocking2.0: --- → ?
Keywords: regression
The new test case causes the error on Firefox 4 also.

It's not specific to OS. I tried on Win7 64bit with 4GB RAM and i5-750. No other processes running and multiple cores are going above 50% usage.

Also, the firefox menus don't function at all when the video is playing on a size background.
Reporter, are you sure that this worked better with Firefox 3.6.0~3.6.3 ? When I look at the possible regression range, I see a consistent high CPU usage ever since the code for background-size landed. Tested with Flash 10.1 r53

Of course, it is posible that an earlier version of Flash (10.0 r45 ?) performed better. The release of Flash 10.1 coincided with the release of Firefox 3.6.4 more or less.

--
regression: 20090729 - 20090730

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=55fd6820c596&tochange=36a36a9c942b

--> bug 189519
(In reply to comment #6) 
> Of course, it is posible that an earlier version of Flash (10.0 r45 ?)
> performed better. The release of Flash 10.1 coincided with the release of
> Firefox 3.6.4 more or less.

Well, that doesn't appear to be the case. I tested Flash 10.0 r45 and I get the same high CPU usage (fx 3.6.8, Camino nightly (Gecko 1.9.2.9pre) and Minefield trunk builds.

I also found an old Firefox 3.6.3 release candidate, and the same issue is apparent.
I just tried firefox 3.6.2 from http://www.oldapps.com/firefox.php?old_firefox=77

I get high cpu usage with flash 10.1. But it seems like the menus and adjusting volume is more responsive, though I can visually see the effects on the video.

I had thought it started with 3.6.4 because that's when user's going to a website using the background-size with flash content first started to complain about the speed issues. I just tried the site with 3.6.2 and the mouse events in the flash games do not get recognized consistently. Maybe 1 out of 6 clicks are actually recognized. 

It does seem that in 3.6.4, cpu usage goes up across all cores(OOPP effect?). But in 3.6.2, it maxes out a single core.
I just tried firefox 3.6.2 from http://www.oldapps.com/firefox.php?old_firefox=77

I get high cpu usage with flash 10.1. But it seems like the menus and adjusting volume is more responsive, though I can visually see the effects on the video.

I had thought it started with 3.6.4 because that's when user's going to a website using the background-size with flash content first started to complain about the speed issues. I just tried the site with 3.6.2 and the mouse events in the flash games do not get recognized consistently. Maybe 1 out of 6 clicks are actually recognized. 

It does seem that in 3.6.4, cpu usage goes up across all cores(OOPP effect?). But in 3.6.2, it maxes out a single core.
Not blocking on this for 1.9.2. If it is indeed found to be a regression in 3.6.4 (doesn't sound like it), please renominate.
blocking1.9.2: ? → -
Same deal with 2.0.
blocking2.0: ? → -
This has been fixed by Layers. Plug-ins now get their own layer and doesn't require the gradient to repaint.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: