1070772 - 200% perf regression Scroll slow and laggy due to landing Bug 994081

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[Alice0775 White]

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.

Comment 1

[Alice0775 White]

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

Comment 2

[Alice0775 White]

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();
})();

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

This seems to be a regression from bug 994081?

Comment 4

[Michael Wu [:mwu]]

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.

Comment 5

[Alice0775 White]

(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

Comment 6

[Alice0775 White]

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

Comment 7

[Michael Wu [:mwu]]

Attachment: Optimize images to DIB in DrawTargetCairo

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

Comment 8

[Michael Wu [:mwu]]

https://tbpl.mozilla.org/?tree=Try&rev=84d5437482a7

Comment 9

[Michael Wu [:mwu]]

https://tbpl.mozilla.org/?tree=Try&rev=807c082feb9e

Comment 10

[Timothy Nikkel (:tnikkel)]

(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?

Comment 11

[Alice0775 White]

(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

Comment 12

[Michael Wu [:mwu]]

Attachment: Optimize images to DIB/D2D in DrawTargetCairo

Hmmm, maybe we want D2D surfaces instead?

Comment 13

[Michael Wu [:mwu]]

https://tbpl.mozilla.org/?tree=Try&rev=08a0ee508f89

Comment 14

[Michael Wu [:mwu]]

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

Comment 15

[Matt Woodrow (:mattwoodrow)]

(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.

Comment 16

[Alice0775 White]

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