Jeff Muizelaar [:jrmuizel] Reporter
	Description • 6 years ago

I see 14ms in the middle of the page.

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 1 • 6 years ago

We should find out what this is before we decide on the urgency

	Jeff Muizelaar [:jrmuizel] Reporter
	Comment 2 • 6 years ago

I put up a rough stand alone copy at https://jrmuizel.github.io/webrender/meet.html

	Jeff Muizelaar [:jrmuizel] Reporter
	Comment 4 • 6 years ago

Glenn, any thoughts on what might be going on here?

	Glenn Watson [:gw]
	Comment 5 • 6 years ago

Looks like there are at least a few things going on here:

- 5 alpha targets are allocated, almost all for clip masks. But the vast majority of these seem to be redundant.
- We're not yet caching those clips masks either, so we pay the cost for that redundancy every frame.
- There are some very expensive image and blend blits - 3 full size color targets are allocated.
- My guess is that these are hitting the slow opacity path needlessly (there is an existing WR bug for this).
- Even if they're running more expensive filters, we should be caching those.
- There is a ridiculously high primitive count in the middle of the page - ~1400 visible primitives where there are seemingly just a few images, < 10 text runs, and a few buttons. Perhaps there are a huge number of overlays or something like that, which we can eliminate / cache in one rendered target.

This is a good test case, thanks!

	Glenn Watson [:gw]
	Comment 6 • 6 years ago

I'll paste more detailed info here once I run it through a GPU profiler and confirm some of those theories above.

	Glenn Watson [:gw]
	Comment 7 • 6 years ago

<div id="5ad4c30efcd52" class="component page-object image" style="position: absolute; width: 1300px; height: 557px; display: block; cursor: inherit; z-index: 78; left: 0px; top: 1624px; transform: translate(0px, 0px) rotate(0deg) scale(1, 1); opacity: 0.93;" data-container-id="5abe9ac313f7e"><img style="display: block; border-width: 0px; box-shadow: none;" src="rising-stars-desktop-final_data/slide3-separated-adelle-full.png" width="1300" height="557"></div>

This node contains an image 2600 x 1114, with an opacity filter 0.93. It's then repeated 4 times directly after one another in the HTML, which seems very odd. So that's a large number of full-screen opacity blits.

We'll get some big wins here by:

 * Caching opacity filters (and we'll detect that the same image/filter is repeated four times and skip doing that work).
 * Optimizing the opacity filter (it currently runs through the expensive blend shader, should be using hardware opacity).
 * Having a fast path for opacity filters that contain a single image (element) by just drawing them directly with a color scale (this would actually be optimal, and mean the above caching changes don't apply in this case).

	Glenn Watson [:gw]
	Comment 8 • 6 years ago

I opened a PR for collapsing simple opacity filters: https://github.com/servo/webrender/pull/2680.

This drops the GPU time on that part of the page from ~14ms to ~9ms on my local machine.

There's still work to be done on the redundant clip mask generation, and the large image overdraw, but this is a start.

	Jeff Muizelaar [:jrmuizel] Reporter
	Comment 9 • 6 years ago

Tentatively moving to Dan.

	Jeff Muizelaar [:jrmuizel] Reporter
	Comment 10 • 6 years ago

I'll check how this looks on Nvidia hardware

	Jeff Muizelaar [:jrmuizel] Reporter
	Comment 11 • 6 years ago

This seems good enough on Nvidia hardware. Not blocking release.