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

Status: NEW

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

Description

[Mayank Bansal]

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

Comment 1

[Mayank Bansal]

non-WR : https://perfht.ml/2OIf8QP

Comment 2

[Mayank Bansal]

bug 1452832 may be relevant here too

Comment 3

[Maire Reavy [:mreavy]]

Jeff -- is this the same as bug 1452832?

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Bug 1452832 might help but eliminating native widgets from content is the true fix.

Comment 5

[Mayank Bansal]

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.

Comment 6

[Mayank Bansal]

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

Comment 7

[Jeff Muizelaar [:jrmuizel]]

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

Comment 8

[Nicolas Silva [:nical]]

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.

Comment 9

[Mayank Bansal]

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

Comment 10

[Mayank Bansal]

ni? for comment #9.

Comment 11

[Nicolas Silva [:nical]]

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.

Comment 12

[Gregory Pappas [:gregp]]

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

Comment 13

[Mayank Bansal]

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

Comment 14

[Gregory Pappas [:gregp]]

(In reply to Mayank Bansal from comment #13)

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

Are you sure? https://hg.mozilla.org/mozilla-central/rev/b18532ba7066 says it should be in build 20221110092309

Comment 15

[Mayank Bansal]

And here is the profile from https://hg.mozilla.org/mozilla-central/rev/963d3b67f5243687fcb5bc122a22a536caa9a9fd : https://share.firefox.dev/3UDk6Qq