1509672 - theoldreader.com has lots of jank when scrolling list view (slow composites)

Status: RESOLVED FIXED

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

Description

[Jan Alexander Steffens [:heftig]]

theoldreader.com has lots of jank when scrolling through articles in list view (articles collapsed to a single line), especially when scrolling off the end of the list (showing white space).

https://perfht.ml/2FGHlY4
Screenshot of WR profiler: https://paste.xinu.at/1L47x/


GPU: GeForce GTX 980M/PCIe/SSE2
Driver Version: 4.6.0 NVIDIA 415.18

Slow Frame #02: Frame 4203(https://theoldreader.com/folders/56a2c651091452555b000001) CONTENT_FRAME_TIME 6606 - Transaction start 0.598491, main-thread time 6.817456, full paint time 10.033015, Skipped composites 0, Composite start 16.431292, Resource upload time 0.000379, GPU cache upload time 0.465634, Render time 1082.557255, Composite time 1085.233756
Slow Frame #03: Frame 4204(https://theoldreader.com/folders/56a2c651091452555b000001) CONTENT_FRAME_TIME 6602 - Transaction start 0.349908, main-thread time 5.935911, full paint time 9.430004, Skipped composites 0, Composite start 16.610957, Resource upload time 0.000472, GPU cache upload time 0.889210, Render time 15.577260, Composite time 1084.120029
Slow Frame #04: Frame 1825(https://theoldreader.com/folders/56a2c651091452555b000001) CONTENT_FRAME_TIME 5537 - Transaction start 0.805989, main-thread time 6.493588, full paint time 11.212490, Skipped composites 0, Composite start 529.009357, Resource upload time 0.000241, GPU cache upload time 3.558096, Render time 292.726835, Composite time 394.660291
Slow Frame #05: Frame 3660(https://theoldreader.com/folders/56a2c651091452555b000001) CONTENT_FRAME_TIME 5425 - Transaction start 0.905752, main-thread time 6.003212, full paint time 10.586326, Skipped composites 0, Composite start 475.656975, Resource upload time 0.000242, GPU cache upload time 3.178380, Render time 330.118223, Composite time 429.411322
Slow Frame #06: Frame 2477(https://theoldreader.com/folders/56a2c651091452555b000001) CONTENT_FRAME_TIME 5274 - Transaction start 0.692442, main-thread time 6.620447, full paint time 11.647429, Skipped composites 0, Composite start 497.401672, Resource upload time 0.000226, GPU cache upload time 8.341524, Render time 291.682114, Composite time 382.355961
Slow Frame #07: Frame 4614(https://theoldreader.com/folders/56a2c651091452555b000001) CONTENT_FRAME_TIME 5267 - Transaction start 0.400606, main-thread time 6.134961, full paint time 10.336371, Skipped composites 0, Composite start 538.279856, Resource upload time 0.000257, GPU cache upload time 1.099613, Render time 246.508139, Composite time 340.008528
Slow Frame #08: Frame 2843(https://theoldreader.com/folders/56a2c651091452555b000001) CONTENT_FRAME_TIME 5214 - Transaction start 0.391892, main-thread time 8.628990, full paint time 13.519809, Skipped composites 0, Composite start 320.006942, Resource upload time 0.000364, GPU cache upload time 3.079354, Render time 274.576648, Composite time 549.390307
Slow Frame #09: Frame 1576(https://theoldreader.com/folders/56a2c651091452555b000001) CONTENT_FRAME_TIME 5141 - Transaction start 1.082948, main-thread time 7.441802, full paint time 12.842178, Skipped composites 0, Composite start 279.294050, Resource upload time 0.000240, GPU cache upload time 3.647293, Render time 296.933677, Composite time 578.573331
Slow Frame #10: Frame 2555(https://theoldreader.com/folders/56a2c651091452555b000001) CONTENT_FRAME_TIME 5099 - Transaction start 0.416958, main-thread time 8.487367, full paint time 13.498112, Skipped composites 0, Composite start 266.612998, Resource upload time 0.000254, GPU cache upload time 2.822382, Render time 294.118966, Composite time 583.638196

Comment 1

[Jeff Muizelaar [:jrmuizel]]

It looks like we have really bad composite times here. Glenn or Dzmitry do you want to take a look to see what we can do. Maybe picture caching will fix it?

Comment 2

[Dzmitry Malyshau [:kvark]]

Could we have one of those pages as HTML saved, so that we don't have to register there for a repro, please?

Comment 3

[Jeff Muizelaar [:jrmuizel]]

The SingleFile addon can be useful for saving pages like this.

Comment 4

[Jan Alexander Steffens [:heftig]]

Attachment: (37) The Old Reader (2018-11-27 4_49_18 PM).html

Here you go. I sanitized it a bit but it still shows the issue.

The scroll bar seems to be broken but the wheel still scrolls.

Comment 5

[Dzmitry Malyshau [:kvark]]

Thank you, Jan!

Here are my observations so far:
  1. In the first pass, we render to 147 layers of an array texture. We don't appear to be reusing the existing layers efficiently, and having that many render target switches easily kills the renderer performance (switching render targets is one of the heaviest operations for GPU/driver).
  2. Each row of the table is represented by 3 draw calls: image for the borders, solid for the filling/rectangles, and then text. This workload doesn't batch well at all. We should be able to batch more aggressively given some spatial partitioning scheme.

Comment 6

[Glenn Watson [:gw]]

I tried to load the attachment with the saved page, and it doesn't seem to reproduce for me. Is there a set of steps I need to take when I load that attachment to see the issue (apart from just scrolling?).

It's not super fast, but it's easily holding 60 fps for me. I see a fairly reasonable number of texture cache layers and 2 render targets.

The batching could definitely be better, but I don't see to be seeing anything like what is reported above.

Comment 7

[Glenn Watson [:gw]]

Oh wait, I see how to reproduce it now - it seems to depend on the width of the window / page layout in some way. In some cases it doesn't decide it needs all those clip masks.

Picture caching will probably mask this issue, but it seems likely to just be a straight bug - I can't see any reason why it should be allocating that many targets and clip masks for that page.

Comment 8

[Dzmitry Malyshau [:kvark]]

(In reply to Glenn Watson [:gw] from comment #7)
> it seems to depend on the width of the window / page layout in some way

Our texture allocator becomes very grumpy (read: inefficient) when the requested sizes approach the allocated page sizes. And since our default page size is 2K, you aren't going to see this effect on a smaller window. With a 4K screen, I can see this issue manifesting itself in a lot of common pages, e.g. HN. Fortunately, my WR PR addresses this issue in full.

Comment 9

[Jan Alexander Steffens [:heftig]]

This seems to be fixed!

Comment 10

[Mayank Bansal]

(In reply to Dzmitry Malyshau [:kvark] from comment #5)

>   2. Each row of the table is represented by 3 draw calls: image for the
> borders, solid for the filling/rectangles, and then text. This workload
> doesn't batch well at all. We should be able to batch more aggressively
> given some spatial partitioning scheme.

Any bug for tracking this?

Comment 11

[Dzmitry Malyshau [:kvark]]

This isn't super bad in this case, it's just something where we could be a lot better. We have a solution described in "Extreme batching" section of https://github.com/servo/webrender/issues/3390