Open Bug 1493359 Opened 6 years ago Updated 2 years ago

https://lab.hakim.se/domtree/ is slower with WR

Categories

(Core :: Graphics: WebRender, defect, P5)

defect

Tracking

()

People

(Reporter: mayankleoboy1, Unassigned)

References

(Blocks 3 open bugs)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0 Build ID: 20180921220134 Steps to reproduce: enable WR go to https://lab.hakim.se/domtree/ Actual results: poor performance Also, once during the rotation, the flying objects disappear for a second, and then appear distorted https://perfht.ml/2OIcLxq Expected results: not so
Summary: https://lab.hakim.se/domtree/ is slow on WR → https://lab.hakim.se/domtree/ is slower with WR
bug 1452832 may be relevant here too
See Also: → 1452832
Jeff -- is this the same as bug 1452832?
Flags: needinfo?(jmuizelaar)
Priority: -- → P4
Bug 1452832 might help but eliminating native widgets from content is the true fix.
Flags: needinfo?(jmuizelaar)
Depends on: 1452832

2019-01-08T00:00:23: INFO : Narrowed inbound regression window from [f1ce520b, 23941690] (3 builds) to [f1ce520b, 996bf60e] (2 builds) (~1 steps left)
2019-01-08T00:00:23: DEBUG : Starting merge handling...
2019-01-08T00:00:23: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=996bf60e0fce90cc42e7b59201d56ba0947b8cf2&full=1
2019-01-08T00:00:24: DEBUG : Found commit message:
Bug 1415987. Use ChooseScale to choose a scale in WebRender. r=jrmuizel

2019-01-08T00:00:24: DEBUG : Did not find a branch, checking all integration branches
2019-01-08T00:00:24: INFO : The bisection is done.
2019-01-08T00:00:24: INFO : Stopped

No idea why, but bug 1415987 massively improved this testcase with WR enabled.

Depends on: 1415987
Priority: P4 → P5

@Jeff: I'm curious why bug 1415987 improved this bug, and bug 1448926 so much. Do you have an idea?

Flags: needinfo?(jmuizelaar)

bug 1415987 made it so that we don't redraw the controls everytime that the scale changes.

Flags: needinfo?(jmuizelaar)

On the render backend we spend a very large amount of time inserting into a BSP tree for plane splitting. The time is spent allocating many small vectors during each recursion of the inderstion function.

The scene is also re-built a lot so the scene builder thread is pretty much 100% busy, a lot fo the time being spent in vector allocations while adding primitives.

Latest profile : https://share.firefox.dev/3oODjOA

  1. 50% of WRRenderBackend is spent in etagere (the new allocator). Is this expected ?
  2. It feels similar to non WR now. Do you see any other low hanging fruits here, or does this page have any specific perf issue that you want to track ? If not, happy to close this bug

ni? for comment #9.

Flags: needinfo?(nical.bugzilla)

50% of WRRenderBackend is spent in etagere (the new allocator). Is this expected ?

It's not expected. Oddly, when profiling locally I see all of the time being spent in add_split_plane and the atlas allocator doesn't show up, which probably indicates that after a long session, the cache can get into a state where atlas allocations become more expensive, which is worth investigating.

I think that there's enough room for improvements here, including low hanging fruits with the plane splitting code, to keep this bug open.

Flags: needinfo?(nical.bugzilla)
See Also: → 1768984
Severity: normal → S3

Does this look any better with the patches from bug 1768984?

Flags: needinfo?(mayankleoboy1)

This is the profile from latest nightly (which doesnt have patches from bug 1768984): https://share.firefox.dev/3tkdkDy

Flags: needinfo?(mayankleoboy1)
Duplicate of this bug: 713532
You need to log in before you can comment on or make changes to this bug.