1308695 - [Performance] Rewrite request waterfall graph with canvas

Status: NEW

(DevTools :: Netmonitor, defect, P2)

Description

[Ricky Chien [:rickychien] (inactive)]

After moving drawWaterfallBackground to its own module, we're going to refactor waterfall component and do not hardcode canvas anymore.

- Use d3.js (which is in devtools/client/shared/vendor/d3.js) to draw waterfall if it's possible.

Comment 1

[Ricky Chien [:rickychien] (inactive)]

Someone already built a similar react component https://www.npmjs.com/package/react-waterfall but the repo is deprecated. We might want to take a look and contact with author to setup and reuse codebase.

Comment 2

[Tim Nguyen :ntim]

I don't see why we need a new component here. We can simply append the canvas once into the DOM then position it using CSS behind the waterfall.

Comment 3

[Ricky Chien [:rickychien] (inactive)]

Remove document.mozSetImageElement() which is not standard APIs

Comment 4

[Tim Nguyen :ntim]

(In reply to Ricky Chien [:rickychien] from comment #3)
> Remove document.mozSetImageElement() which is not standard APIs

What I've suggested in comment 2 does not rely on mozSetImageElement().

Comment 5

[Julien Cristau [:jcristau]]

Mass wontfix for bugs affecting firefox 52.

Comment 6

[Jan Honza Odvarko [:Honza] (always need-info? me)]

See also:
bug 1350969 comment #9
bug 1350969 comment #10

Honza

Comment 7

[Ricky Chien [:rickychien] (inactive)]

Chromiumis network monitor is using canvas to implement the waterfall graph entirely rather than HTML div. It might gain much more performance improvement in particular when loading large amount of data in complicated website (CNN, BBC). 

One single canvas on the right side of request list can avoid drawing many div elements and reduce CSS reflow for waterfall elements. Because every network request comes along with requests-list-timings div, and inside the div will create many elements for connection state such as blocked, dns, connect, send, wait and receive. These state elements will cause reflow each time when new request arrives and then resize waterfall again.

Thing boils down to that canvas would be a good solution in this case. Let's remove waterfall div and embrace canvas for victory.

Comment 8

[Ricky Chien [:rickychien] (inactive)]

Attachment: Chromium network monitor with canvas waterfall.png

Comment 9

[[e-mail]]

In the experiment, I can see some FPS improvement without waterfall when loading the same website (http://www.bbc.com/news).

With waterfall (no change)
https://perfht.ml/2xYKnCK
from the record of browser console's performance tab 
> 4.26fps (235ms) - 60 fps



No waterfall at all (remove waterfall column & remove RequestListHeader::componentDidMount/componentDidUpdate/componentWillUnmount for redraw background)
https://perfht.ml/2xZ30q7
from the record of browser console's performance tab 
> 2.50fps (400ms) - 60fps



At the mean time, I saw Chrome

* did not showing string on waterfall column
* the waterfall column is fixed when resize


So I add extra test with waterfall but not render the text box
> 2.56~2.75fps(363~390ms) ~ 60fps


And with waterfall but not plot background lines
from the record of browser console's performance tab 
> 3.05fps (327ms) - 60fps


Need more analysis when the connector bug 1410782 is fixed.

Comment 10

[[e-mail]]

Sorry the number is missplaced, here's the right one

With waterfall (no change)
> 2.50fps (400ms) - 60fps

No waterfall at all (remove waterfall column & remove RequestListHeader::componentDidMount/componentDidUpdate/componentWillUnmount for redraw background)
> 4.26fps (235ms) - 60 fps

Comment 11

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Fred: can you also try to remove existing CSS transformation/scaling, profile again and see what the difference/improvement is?

Honza

Comment 12

[[e-mail]]

remove transitions did show some performance improvement for the worst fps case

With waterfall (no change)
> 2.39fps - 60fps

Without scaling in .requests-list-timings & .requests-list-timings-total
> 3.79fps - 60fps

Comment 13

[[e-mail]]

The DAMP show -4.58% (med) when removed css transform for in netmonitor.css
 
simple.netmonitor.open.DAMP 535.19 > 510.66

https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=mozilla-central&newProject=try&newRevision=3730ddcda70576de724116fbd6496c99ed1e2e4b&originalSignature=edaec66500db21d37602c99daa61ac983f21a6ac&newSignature=edaec66500db21d37602c99daa61ac983f21a6ac&filter=netmonitor&framework=1&selectedTimeRange=172800

Comment 14

[[e-mail]]

no css transform will decrease the open/close time

simple.netmonitor.open 535.19 > 510.66 -4.58% (med)
simple.netmonitor.close 55.08 > 52.82 -4.1% (low)

Also I realized after upgrade to react 15.6.x we can set css variables in component, so `setScalingStyles` is not needed now 
http://searchfox.org/mozilla-central/source/devtools/client/netmonitor/src/components/RequestListContent.js#120

The try result
https://treeherder.mozilla.org/#/jobs?repo=try&revision=655f1538d45f

Comment 15

[[e-mail]]

set css variables in react component looks good for netmonitor

Simple.netmonitor.open 535.19 > 512.56 -4.23% (med)

https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=mozilla-central&newProject=try&newRevision=655f1538d45fbe8821315ce69f44d0b257955ae0&originalSignature=edaec66500db21d37602c99daa61ac983f21a6ac&newSignature=edaec66500db21d37602c99daa61ac983f21a6ac&filter=netmonitor&framework=1&selectedTimeRange=172800

But it regress inspector and styleeditor??
https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=mozilla-central&newProject=try&newRevision=655f1538d45fbe8821315ce69f44d0b257955ae0&originalSignature=edaec66500db21d37602c99daa61ac983f21a6ac&newSignature=edaec66500db21d37602c99daa61ac983f21a6ac&framework=1&selectedTimeRange=172800

Comment 16

[[e-mail]]

remove auto scroll can improve complicated requestsFinished case by 1.5%

complicated.netmonitor.requestsFinished 9,536.79 > 9,392.50 -1.51% (med)

https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=mozilla-central&newProject=try&newRevision=0ecc6c65c8b93ac1be57281d46a3a0cecca897cf&originalSignature=edaec66500db21d37602c99daa61ac983f21a6ac&newSignature=edaec66500db21d37602c99daa61ac983f21a6ac&filter=netmonitor&framework=1&selectedTimeRange=172800