Closed Bug 602126 Opened 15 years ago Closed 15 years ago

Excessive CPU usage due to progress lines

Categories

(Core :: Graphics, defect)

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

Tracking

()

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: matjk7, Assigned: Margaret)

References

Details

(Keywords: perf, regression)

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20101005 Firefox/4.0b7pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20101005 Firefox/4.0b7pre For some odd reason the patch in bug 596812 causes progress lines to sky-rocket CPU usage. Reproducible: Always This should probably block beta7.
Blocks: 596812
blocking2.0: --- → ?
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
Can we quantify "sky rocket"? Is this OS specific?
(In reply to comment #1) > Can we quantify "sky rocket"? Is this OS specific? 30-40% on a c2d @ 3ghz system using win7.
That's ... pretty high. David, any ideas what in the CSS that Margaret created over in bug 596812 might be causing this performance hit? I'm not seeing it on OS X, fwiw.
Though I do see a spike, now that I'm looking for it.
Speculatively assigning to adw who made the change; we can't ship b7 without fixing this.
Assignee: nobody → adw
blocking2.0: ? → beta7+
I didn't do progress lines, Margaret did, so surely she or Dao would know what's going on better than me.
Assignee: adw → nobody
Ooops! Margaret: j'accuse!
Assignee: nobody → margaret.leibovic
Keywords: perf, regression
OK, I profiled this locally using a build without -fomit-frame-pointers on this URL <http://gavinsharp.com/os/slow.php?time=50&url=http://gavinsharp.com>, and it looks like we're spending all of our time painting. I guess the graphics guys would probably be the best people to look at this. Here's a link to the shark profile, with symbols embedded: http://people.mozilla.com/~eakhgari/progressbar.mshark
Assignee: margaret.leibovic → nobody
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
Tentatively assigned to Joe.
Assignee: nobody → joe
Gradients are slow - we should replace this with a PNG.
Assignee: joe → margaret.leibovic
(In reply to comment #10) > Gradients are slow - we should replace this with a PNG. Presumably an APNG.
Also, can we please have a perf bug filed on the "gradients are slow" bit? Simply shrugging our shoulders there seems like of a bit of a strange reaction. (Why are they slow? How can we make them fast?)
(In reply to comment #11) > (In reply to comment #10) > > Gradients are slow - we should replace this with a PNG. > > Presumably an APNG. Stephen, could you make this image for me?
(In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #10) > > > Gradients are slow - we should replace this with a PNG. > > > > Presumably an APNG. > > Stephen, could you make this image for me? I can, but I don't think an APNG is going to work here. Unless we use it for a glowing motion effect. It sounds like what we want is just to use images for the background fill instead of gradients.
This is kind of a problem -- we've been telling people to switch to using CSS gradients precisely because we didn't want to deal with repeating images and crap for emulating gradients. There's really no reason why gradients should be slow, especially with hw accel -- they can generated directly on the hardware!
(In reply to comment #15) > This is kind of a problem -- we've been telling people to switch to using CSS > gradients precisely because we didn't want to deal with repeating images and > crap for emulating gradients. There's really no reason why gradients should be > slow, especially with hw accel -- they can generated directly on the hardware! Well, a GradientLayer would be one idea for doing this I guess, although we get the subpixel AA problems and all. Gradient drawing also has no SIMD support in pixman though if I recall correctly, especially for linear gradients, but also partly for radial ones SSE2 could speed up the drawing considerably. Looking at the current method pixman produces gradients, I'm not sure it would be easy to fiddle in there though.
I ripped the gradient out and switched it to a PNG file for the connecting state with no apparent change in CPU usage. Setting both the gradient and PNG instances to run the connecting state resulted in around 12–15% CPU usage. Hardly scientific but I doesn't think it is the gradient causing the spike.
The gradient was about 8% of the total profile. Not using it might not make a noticeable difference in Activity Monitor.
(In reply to comment #18) > The gradient was about 8% of the total profile. Not using it might not make a > noticeable difference in Activity Monitor. So, does that mean that using an image instead of a gradient is not a good enough workaround for this bug?
If the problem is with the animation CSS in general, we could use an APNG for the background while the progress meter is in the connecting state, then go back to using gradients for the background fill as the progress meter starts making progress. Since we weren't noticing CPU problems before the connecting state animation landed, this bug should just involve making changes to the CSS for that state.
How do we determine the animation frequency? Do we run it off of mozRequestAnimationFrame, or timeouts, or something else?
(In reply to comment #21) > How do we determine the animation frequency? Do we run it off of > mozRequestAnimationFrame, or timeouts, or something else? The animation frequency is determined by the -moz-transition-duration set here: http://mxr.mozilla.org/mozilla-central/source/browser/themes/pinstripe/browser/browser.css#921. (As a side note, this should probably be moved out of browser/themes/ to browser/base/content/browser.css).
OK, so that works off refresh driver. Looking at that profile, there's a bunch of gl stuff there, lots of the usual Mac "event loop and appkit take up a quarter of your time" stuff, box-shadow painting(?), display list construction... If I turn off gl, quartz debug update flashing only shows the progress line flashing, which is good.
(In reply to comment #23) > box-shadow painting(?) This is probably the faint white line under the address bar text field border.
Somebody should profile this on Windows, too. All the obvious stuff in the Mac profile is OpenGL or Mac specific.
Bug 602964 makes this invalid.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Though we've resolved this one, I would really really love to see a spinoff opened about the specific issue so that, one day, we can have fast gradients. Might be easiest to just re-open this one; I'll leave that up to Joe.
I just wanted to point this out, as I think it might be relevant to the gradient issue. Since it doesn't look like there's another bug open, I'll just leave it here: http://lists.freedesktop.org/archives/xorg-announce/2010-October/001434.html A new pixman release 0.19.6 is now available. This is a release candidate for a stable 0.20.0 release. News since 0.19.4: - Much improved radial and linear gradients [Andrea Canciani] - Performance improvements, especially for ARM [Siarhei Siamashka] - Improved performance for the SSE2 backend [Liu Xinyun] - Plus a number of bug fixes and improvements to the test suite [Dmitri Vorobiev, Mika Yrjola, Søren Sandmann Pedersen]
(In reply to comment #28) > A new pixman release 0.19.6 is now available. This is a release > candidate for a stable 0.20.0 release. This landed on mozilla-central earlier today (bug #604168). I don't expect it to help this bug much.
You need to log in before you can comment on or make changes to this bug.