+++ This bug was initially created as a clone of Bug #1001593 +++ The following SVG benchmark is significant slower in Firefox30 than Firefox 29 with disable HWA. Steps To reproduce: 1. Start Firefox with Disable HWA 2. Open http://themaninblue.com/experiment/AnimationBenchmark/svg/ Actual Results: * Firefox 29: more than 17 fps * Firefox 30: less than 2 fps * Firefox 31: less than 2 fps Regression window(m-i): Good: >17fps https://hg.mozilla.org/integration/mozilla-inbound/rev/1b4b7d198185 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140228113428 Bad: <2fps https://hg.mozilla.org/integration/mozilla-inbound/rev/4895aa1f1ee5 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140228122129 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9a04137a9c84&tochange=4895aa1f1ee5 Suspect: Bug 976877

In local build, Last Good: 1b4b7d198185 First Bad: 4e0303f0aebc Regressed by: 4e0303f0aebc Matt Woodrow — Bug 976877 - Don't simplify invalidation regions since it leads to poor results. r=roc

Matt, Can you have a look at this?

This basically backs out the offending patch and just bumps up the rectangle counts instead. It doesn't appear to regress the original testcase, but massively improves performance on this one.

sorry had to back this out for test failures like https://tbpl.mozilla.org/php/getParsedLog.php?id=39122304&tree=Mozilla-Inbound

Matt, are you able to revive the work here in time for our FF30 release? This is a new regression to 30 so if we have a low-risk landing that could take care of it, let's get that into next week's beta.

https://tbpl.mozilla.org/?tree=Try&rev=48d3601385f8 https://hg.mozilla.org/integration/mozilla-inbound/rev/cf90b93d9617

Without a beta uplift nomination, this missed the last beta that went to build today. Will have to wontfix for 30 and look for an Aurora nomination to get this landed to 31.

(In reply to Lukas Blakk [:lsblakk] from comment #9) > Without a beta uplift nomination, this missed the last beta that went to > build today. Will have to wontfix for 30 and look for an Aurora nomination > to get this landed to 31. That's unfortunate, but I felt it needed to make sure there weren't any real regressions, sort out the talos results etc. I'll request aurora approval now.

Comment on attachment 8413516 [details] [diff] [review] Simplify again [Approval Request Comment] Bug caused by (feature/regressing bug #): Bug 976877 User impact if declined: Poor performance on some very dynamic pages Testing completed (on m-c, etc.): Been on m-c for a few days, manually confirmed it fixes the issue. Risk to taking this patch (and alternatives if risky): Very low risk, just modifies the amount of overdraw we have to reduce the time spent computing it precisely. String or IDL/UUID changes made by this patch: None

Joel, is this something that we could include or replicate in talos so we catch regressions like this in svg? Thanks!

Liz, great question. We could add this to Talos, it found an issue that our current SVG tests didn't catch- so that helps justify it. We would need to agree on a few things such as how to determine how long to measure before recording FPS and if FPS is all we want to measure. Matt, would you like to see this in Talos?

I like this benchmark; I think we should even consider adding the HTML and Canvas versions to Talos as well. A few things would need to be fixed: The tests currently use setInterval, we should rather use requestAnimationFrame with ASAP mode. And the -moz- prefixes would need to be removed in the HTML version since we no longer support -moz-border-radius and -moz-box-shadow.

(In reply to Markus Stange [:mstange] from comment #15) > I like this benchmark; I think we should even consider adding the HTML and > Canvas versions to Talos as well. A few things would need to be fixed: The > tests currently use setInterval, we should rather use requestAnimationFrame > with ASAP mode. And the -moz- prefixes would need to be removed in the HTML > version since we no longer support -moz-border-radius and -moz-box-shadow. Sounds great. I could add it to my backlog, or, if anyone else feels like having a go at it, I'll be able to help where needed.

Yeah, I think all versions of this benchmark would be useful, especially since they've already proven to find performance issues that our current set of tests don't.

filed bug 1020365 to track adding these tests to Talos!

Reproduced with Fx 30 beta 8 (Build ID: 20140527133511). Verified fixed with Firefox 31 beta 1 (Build ID: 20140610163407) on Windows 7 x32 [1] - more than 32 FPS with HWA disabled. [1] Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Firefox/31.0