1710978 - The WR display list on youtube.com has a lot of clips

Status: NEW

(Core :: Graphics: WebRender, defect)

Description

[Glenn Watson [:gw]]

When visiting youtube.com, I noticed that WR ends up with a display list containing 2496 clip instances defined. This seems excessive since it's mostly rectangles.

Let's investigate what causes these and see if we can reduce them on the Gecko side, since that number of clips also affects gecko DL build / conversion and DL serialization times quite badly.

Comment 1

[Glenn Watson [:gw]]

I should note - some of this is probably due to the way WR flattens clips in clip-chains, causing some duplication here we can fix in WR. It still seems a lot higher than on other pages I profiled though.

Comment 2

[Miko Mynttinen]

Attachment: Youtube-dump.txt

Display list and clip manager dump from YouTube.

Comment 3

[Miko Mynttinen]

YouTube seems to build massive display lists. I wrote some code to dump display item distribution of a display list.

Comment 4

[Miko Mynttinen]

Attachment: item-list-with-bg-hittest.txt

Comment 5

[Miko Mynttinen]

Attachment: item-list-without-bg-hittest.txt

Comment 6

[Miko Mynttinen]

These1 two lines are responsible for 1688 out of the 1763 (96%) nsDisplayCompositorHitTestInfo items on the page. Without these additional hit test items, the amount of ClipChain(ClipChainItem) in WRDL goes down from 886 to 609. This is not linear because both ClipManager and HitTestInfoManager can sometimes reuse their results (for example in the case of sibling items).

Comment 7

[Matt Woodrow (:mattwoodrow)]

If I remember correctly, we build nsDisplayCompositorHitTestInfo for most frames, even if the same info is covered by an ancestor, to cover the case where z-index sorting puts something else in between them.

At the point we're serializing the DL into WR format this should all be complete, so could we have tracking of the current hit test area and omit duplicate items at that point?

Comment 8

[Miko Mynttinen]

(In reply to Matt Woodrow (:mattwoodrow) from comment #7)

If I remember correctly, we build nsDisplayCompositorHitTestInfo for most frames, even if the same info is covered by an ancestor, to cover the case where z-index sorting puts something else in between them.

At the point we're serializing the DL into WR format this should all be complete, so could we have tracking of the current hit test area and omit duplicate items at that point?

For hit test items, we have this optimization.

I think the root cause of the issue here is just YouTube being a complicated web page. Regardless whether we create a "sufficient" amount of hit test items or not, Gecko still creates over thousand clipchains.

WR display list:
	Defined clips: 240
	Defined clipChains: 912
	Pushed hit test items: 795
Display list builder (0x7ffee1ce9f28) stats:
	AGRs: 152
	ASRs: 1
	ClipChains: 1160 (unique 739)
** List 0x7ffee1cebd30 (builder: 0x7ffee1ce9f28): total items: 3225
	 ASYNC_ZOOM: 1
	 BACKGROUND: 4
	 BACKGROUND_COLOR: 95
	 BORDER: 70
	 BOX_SHADOW_INNER: 1
	 BUTTON_BORDER_BACKGROUND: 50
	 CANVAS_BACKGROUND_COLOR: 1
	 COMPOSITOR_HITTEST_INFO: 1770
	 CONTAINER: 320
	 FIXED_POSITION: 2
	 IMAGE: 26
	 MASK: 2
	 OPACITY: 241
	 OWN_LAYER: 2
	 SOLID_COLOR: 1
	 SVG_GEOMETRY: 104
	 SVG_WRAPPER: 109
	 TEXT: 266
	 TEXT_OVERFLOW: 9
	 THEMED_BACKGROUND: 3
	 TRANSFORM: 148

and

WR display list:
	Defined clips: 240
	Defined clipChains: 634
	Pushed hit test items: 196
Display list builder (0x7ffeea7e2f18) stats:
	AGRs: 154
	ASRs: 1
	ClipChains: 1269 (unique 849)
** List 0x7ffeea7e4d20 (builder: 0x7ffeea7e2f18): total items: 1496
	 ASYNC_ZOOM: 1
	 BACKGROUND: 4
	 BACKGROUND_COLOR: 95
	 BORDER: 70
	 BOX_SHADOW_INNER: 1
	 BUTTON_BORDER_BACKGROUND: 50
	 CANVAS_BACKGROUND_COLOR: 1
	 COMPOSITOR_HITTEST_INFO: 76
	 CONTAINER: 282
	 FIXED_POSITION: 2
	 IMAGE: 32
	 MASK: 2
	 OPACITY: 240
	 OWN_LAYER: 2
	 SOLID_COLOR: 1
	 SVG_GEOMETRY: 107
	 SVG_WRAPPER: 112
	 TEXT: 259
	 TEXT_OVERFLOW: 6
	 THEMED_BACKGROUND: 3
	 TRANSFORM: 150

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Do we have a sense for what youtube is doing html/css wise that's causing all of the gecko clip chains?

Comment 10

[Matt Woodrow (:mattwoodrow)]

It looks like youtube is using overflow:hidden all over the place, resulting in lots of new clips.

At a glance, it seems like a lot of items don't have bounds that actually extend outside the clip area, so the clip isn't adding any value. No idea what the actual percentage that hit this condition is though.

I wonder if we can detect during item creation that the leaf of the current clip chain has bounds that contain the item bounds, and that they have a matching ASR, and only clip to the next element in the clip chain.

We could also maybe compare the overflow rect of the scroll frame to the size, and skip pushing the clip onto the stack in the first place.

It would be nice if youtube used overflow:clip for these, to avoid the creation of scroll frames.

Comment 11

[Jeff Muizelaar [:jrmuizel]]

Looks like Safari doesn't support overflow: clip yet (https://bugs.webkit.org/show_bug.cgi?id=198230), but perhaps we could suggest they use it in combination with @supports.