Open Bug 1308695 Opened 3 years ago Updated 4 months ago

[Performance] Rewrite request waterfall graph with canvas

Categories

(DevTools :: Netmonitor, defect, P2)

defect

Tracking

(firefox52 wontfix)

Tracking Status
firefox52 --- wontfix

People

(Reporter: rickychien, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [netmonitor])

Attachments

(1 file)

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.
Blocks: netmonitor-html
No longer blocks: 1308504
Depends on: 1308504
Whiteboard: [netmonitor]
Flags: qe-verify+
QA Contact: ciprian.georgiu
Priority: -- → P2
Priority: P2 → P3
Whiteboard: [netmonitor] → [netmonitor-reserve]
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.
Priority: P3 → P1
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.
Remove document.mozSetImageElement() which is not standard APIs
(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().
No longer blocks: netmonitor-html
Priority: P1 → P2
Whiteboard: [netmonitor-reserve] → [netmonitor]
Mass wontfix for bugs affecting firefox 52.
Summary: Refactor Waterfall graph, not use canvas as background → [Performance] Refactor Waterfall graph, not use canvas as background
See Also: → 1355760
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.
Summary: [Performance] Refactor Waterfall graph, not use canvas as background → [Performance] Rewrite request waterfall graph with canvas
Blocks: 1350969
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.
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
@Fred: can you also try to remove existing CSS transformation/scaling, profile again and see what the difference/improvement is?

Honza
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
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
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.