Steps To Reproduce: 1. Open testcase index.html 2. Run the following code in ScratchPad with chrome privilege (function() { function scroll(event) { var top = content.document.documentElement.scrollTop || content.document.body.scrollTop; if (top < 6000) { var evt = content.document.createEvent("KeyboardEvent"); evt.initKeyEvent ("keypress", true, true, window, null, null, null, null, 40, 0) content.document.dispatchEvent(evt) } else { content.removeEventListener("scroll", scroll, false); content.scrollTo(0,0); alert(new Date().getTime() - start); } } content.focus(); content.scrollTo(0,0); var start = new Date().getTime(); content.addEventListener("scroll", scroll, false); scroll(); })(); Actual Results: Scroll slow and laggy There are atleast 2 regressions. #1: 200% slower than previous, Regressed by Bug 994081 #2: 25% slower than the previous, Regressed by Bug 1002992 #1 Regression window(m-i) Good: 6000 msec L:\trunk\2014\06\inbound\firefox inbound 06-Jun-2014 1811 1402051313 https://hg.mozilla.org/integration/mozilla-inbound/rev/4511d9ac1000 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140606104153 Bad: 13000 msec https://hg.mozilla.org/integration/mozilla-inbound/rev/79624417d247 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140606104333 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4511d9ac1000&tochange=79624417d247 Regressed by: Bug 994081 - Convert imgFrame to store and act on a Moz2D SourceSurface instead of a Thebes gfxASurface #2 Regression window(m-i) Bad: 13000 msec https://hg.mozilla.org/integration/mozilla-inbound/rev/e2714481c419 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140606191036 Bad: 16000 msec https://hg.mozilla.org/integration/mozilla-inbound/rev/47fcf180a0b9 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140606192436 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e2714481c419&tochange=47fcf180a0b9 Regressed by: Bug 1002992 - use a bare frame tree walker for image visibility Regarding #2 regression, I will file a separate bug.

testcase https://dl.dropboxusercontent.com/u/33246373/20140922031026.7z

Correct: 2. Run the following code in ScratchPad with chrome privilege (function() { function scroll(event) { var top = content.document.documentElement.scrollTop || content.document.body.scrollTop; if (top < 11000) { var evt = content.document.createEvent("KeyboardEvent"); evt.initKeyEvent ("keypress", true, true, window, null, null, null, null, 40, 0) content.document.dispatchEvent(evt) } else { content.removeEventListener("scroll", scroll, false); content.scrollTo(0,0); alert(new Date().getTime() - start); } } content.focus(); content.scrollTo(0,0); var start = new Date().getTime(); content.addEventListener("scroll", scroll, false); scroll(); })();

This seems to be a regression from bug 994081?

Do you still see this problem on nightly? On nightly I get almost the same performance as ESR 31. It seems about 8% slower or so, but hard to tell since the numbers are noisy. We recently started optimizing scaled images too (bug 1069652), which reduces the amount of copying needed.

(In reply to Michael Wu [:mwu] from comment #4) > Do you still see this problem on nightly? On nightly I get almost the same > performance as ESR 31. It seems about 8% slower or so, but hard to tell > since the numbers are noisy. We recently started optimizing scaled images > too (bug 1069652), which reduces the amount of copying needed. I can reproduce the 200% slow and laggy problem in latest Nightly35.0a1. https://hg.mozilla.org/mozilla-central/rev/790f41c631cc Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 ID:20140923030204

In local build last Good: 4c16ab7d8eef First Bad: 013456bbf74d Regressed by: 013456bbf74d Michael Wu — Bug 994081 - [2/3] Convert imgFrame to SourceSurfaces, r=seth

Just a guess. Going to make a build on try and see if this works.

(In reply to Michael Wu [:mwu] from comment #9) > https://tbpl.mozilla.org/?tree=Try&rev=807c082feb9e The build is available now. Alice could you try it please?

(In reply to Timothy Nikkel (:tn) from comment #10) > (In reply to Michael Wu [:mwu] from comment #9) > > https://tbpl.mozilla.org/?tree=Try&rev=807c082feb9e > > The build is available now. Alice could you try it please? The try-build 12748 13673 13571 14014 13516 12541 https://hg.mozilla.org/try/rev/807c082feb9e Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 ID:20140929120934 FYI The Good build 6468 6784 5449 5933 5567 5950 https://hg.mozilla.org/integration/mozilla-inbound/rev/4511d9ac1000 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140606104153 Latest tinder-box/beta 17206 16005 17608 17325 17241 17124 https://hg.mozilla.org/releases/mozilla-beta/rev/82f4086ba2c7 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140929093101 Latest tinder-box/mozilla-aurora 19713 19507 19239 18883 19152 18923 https://hg.mozilla.org/releases/mozilla-aurora/rev/5d0ec7211d63 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140929004300 Latest tinder-box/mozilla-central 14335 12856 12088 12822 12921 12154 https://hg.mozilla.org/mozilla-central/rev/1be11f0923bc Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 ID:20140929122059

Hmmm, maybe we want D2D surfaces instead?

On second thought, I'd be surprised if this worked since we should be using DrawTargetD2D in this case..

(In reply to Michael Wu [:mwu] from comment #14) > On second thought, I'd be surprised if this worked since we should be using > DrawTargetD2D in this case.. Indeed, I wouldn't expect us to ever get DrawTargetCairo backed by a cairo_d2d_surface.

No longer reproduced. https://hg.mozilla.org/mozilla-central/rev/b6683e141c47c022598c0caac3ea8ba8c6236d42 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 ID:20160407030234