Closed Bug 489291 Opened 16 years ago Closed 15 years ago

Full screen SVG animation causes Firefox 3.5b4pre to hog the CPU and become laggy and unresponsive.

Categories

(Core :: SVG, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: geeknik, Unassigned)

References

()

Details

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090420 Shiretoko/3.5b4pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090420 Shiretoko/3.5b4pre While visiting http://srufaculty.sru.edu/david.dailey/svg/balloon.svg I noticed that the animation wasn't very smooth and that Firefox was acting a little laggy, and I checked task manager and Firefox was hogging teh CPU with usage spiking up to 100%. Reproducible: Always Steps to Reproduce: 1. Open Firefox 3.5b4pre 2. Visit http://srufaculty.sru.edu/david.dailey/svg/balloon.svg Actual Results: Animation is not smooth, Firefox 3.5b4pre is hogging the CPU and becomes laggy and unresponsive. Expected Results: Animation should be smooth, Firefox 3.5b4pre should not hog the CPU, and should not become unresponsive while displaying this page.
Attached image Resizable test case.
Beautiful test case! Being motivated, I made it resizable. Open my attachment, and resize Firefox's window smaller. Animation will get faster a bit. That means, the bigger window size is, the more CPU power is needed to rasterize vector graphics. Generally, this happens because Firefox use software-based rasterization. Similar phenomenon can be observed when you open actively-animated Flash movies directly and make Firefox full-screen. I lightly proofiled this with OProfile on Ubuntu 9.04 using trunk build. Same sluggishness happened. And particularly radical gradient part of libpixman(Software ransterization library which used by Firefox) came top. That part is not vectorized by SIMDs. Some improvements can be done here. Following statement is my opinion. I may be wrong, because I'm still not competent Firefox developer. But, generally, you can't see drastic speed up to the extent where you can watch smooth animations at full-screen like this until we can offload many rasterization processing into GPU. It will take years, because to make it happen, let alone many code rewriting, to justify such effort, we must wait one generation of shift of assumed minimum hardware requirement. In a nut shell, that generation is Vista-compatible one.
I can see a pretty smooth animation using a nightly build [1] on Windows Vista SP2. Of course this will likely be hardware-dependent and of your own notion of smooth, but I compared to the previous 3.5.x release [2], also in Windows, and the result is noticeable. The guilty is likely the path improvements [3] (the moving mountains in the background) and other ones which made it into 3.6, the current release as of a few days ago [4]. :-) I'd suggest confirming this in your setups and closing this as "worksforme". [1] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20100124 Minefield/3.7a1pre (.NET CLR 3.5.30729) [2] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729) [3] http://muizelaar.blogspot.com/2010/01/graphics-performance-in-firefox-36.html [4] https://developer.mozilla.org/devnews/index.php/2010/01/21/firefox-3-6-is-now-available-for-download/
This full screen animation is smoother now than it was before, however, while the tab it is in has focus, it's using 100% of 1 CPU core. I can only imagine how this performs on a single core CPU, but I don't have any of those antiques laying around anymore. I will say that browser is not laggy and unresponsive like it was. But I don't think it should be hogging an entire CPU core. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100124 Firefox/3.7a1pre Hardware: Intel Q9450 2.66ghz Core2Quad, 8GB Corsair DDR2-800, ATI Radeon HD5870, etc. OS: Windows 7 Pro x64
(In reply to comment #3) > This full screen animation is smoother now than it was before, however, while > the tab it is in has focus, it's using 100% of 1 CPU core. [...] > I will say that browser is not laggy and unresponsive > like it was. But I don't think it should be hogging an entire CPU core. I guess that, to accomplish it, Firefox needed to have some sort of "maximum CPU" or an "animation rate limiter" like (Apache Batik) Squiggle. It hogs the CPU while trying to provide the smoothest user experience. It's a matter of opinion if it *should*. ;-) I'm not sure if there's some hidden preference for that; if not, then I'd suggest reporting a new issue or maybe reusing this issue, by updating changing its summary (and lowering priority).
Depends on: 527707
This works great, with no lag, stuttering, etc. with D2D/DW enabled. Not sure there is any other way to make this work smoother. :)
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: