1480945 - XDA forum page scrolls jankily with WR

Status: RESOLVED FIXED

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

Description

[Mayank Bansal]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180803220259

Steps to reproduce:

Enable WR
go to https://forum.xda-developers.com/redmi-note-3/development
Scroll with the mouse wheel/touchpad


Actual results:

page scrolls jankily. Feels like micro-jitters

https://perfht.ml/2ObwVz7


Expected results:

smoooooooooth

Comment 1

[Mayank Bansal]

Attachment: aboutsupport.txt

Comment 2

[Mayank Bansal]

for comparison, here is the non-WR profile: https://perfht.ml/2KqKVCF

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Indeed, there are some longish composites in that WR profile. It runs even worse on Mac.

Comment 4

[Glenn Watson [:gw]]

There's a couple of things going on here:

The draw call count is very high - ~400, which is causing a significant amount of CPU time in the compositor. This looks to be batch breaks due to a lot of overlapping images and text runs. Needs more investigation to see what's going on here. The primitive count is also quite high (~2500) which means the display list times are much higher than usual.

There are also some expensive GPU blurs running sometimes that aren't being cached. Needs more investigation to see where they are coming from.

Comment 5

[Bobby Holley (:bholley)]

Glenn thinks will largely be solved by picture caching.

Comment 6

[Mayank Bansal]

this has become better 

http://bit.ly/2Io1G1Z

Comment 7

[Glenn Watson [:gw]]

The main remaining issue here is that we end up with hundreds of draw calls. The batching code is mostly failing and interleaving hundreds of image / text runs. What we need to do is find out:

• Why the batching doesn't manage to do a better job of these, specifically:

• What are the bounding rects like for all those elements and what is causing so much overlap / batch breaking.

• What are the sources of the image items interleaved with the text runs? Are they from borders, or something else?

• One possibility is that the interleaved items are borders, which are (probably?) opaque. However, we currently treat all borders as transparent. It could be interesting to test how it looks if borders are treated as opaque, as they'll be much easier to batch then in the opaque pass. That's just a guess though - we need to do the investigation above first.

DanG, is this something you have cycles to take on?

Comment 8

[u480271]

Attachment: AlphaBatchList rejection

Comment 9

[u480271]

(In reply to Glenn Watson [:gw] from comment #7)

The main remaining issue here is that we end up with hundreds of draw calls. The batching code is mostly failing and interleaving hundreds of image / text runs. What we need to do is find out:

• Why the batching doesn't manage to do a better job of these, specifically:
• What are the bounding rects like for all those elements and what is causing so much overlap / batch breaking.
• What are the sources of the image items interleaved with the text runs? Are they from borders, or something else?

I looks like a majority of text has text-shadow - of 0.4% of (43, 43, 43). So there is an interleaving of Text/Shadow/Text/Shadow. When looking for batching, the text is contained within it's shadow, so the batching code creates a new batch as soon as the text bounding rect intersects it's shadow rect.

I hacked up a demonstration of where rects are rejected because of intersection in the batching code. (See attached image). If the shadows aren't interspersed with text, the AlphaBatchList code would merge the text into batches because they have compatible keys, skipping the bounding rect intersect test.

Comment 10

[u480271]

Attachment: Screenshot 2019-01-15 17.01.38.png

I modified the alpha batcher to work on World space rects after :gw suggested that comparing Picture space rects was the wrong thing to do. This lead to more batches!

I changed the debugging mode to display the created alpha batches. Each batch is labelled with {batch idx}:{item idx}

Comment 11

[Glenn Watson [:gw]]

With picture caching enabled + the multiple dirty rects support, I see:

Smooth 60 fps when running at 1920 x 2160 on my Intel HD4600.
~50 fps when running at 3840 x 2160 (4k) on my Intel HD4600.

We will want to make further improvements to this in the future, but I think it's probably good enough now to either not be a blocker and/or close. Sound reasonable Jeff?

Comment 12

[Mayank Bansal]

I agree with comment 11. Page is much better now. Not as smooth as non-WR, but acceptable enough

Comment 13

[Jeff Muizelaar [:jrmuizel]]

Good enough for me.

Comment 14

[u480271]

Do we want to accept the shadow collapsing work I did for this bug? (Currently the patches are against Bug 1518840, but I was thinking of moving them to this bug because this was the bug that initiated that work)