1410030 - The background is cleared twice.

Status: RESOLVED FIXED

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

Description

[Nicolas Silva [:nical]]

If the the background of the page is a solid color, we should use the clear color of the set_display_list call instead of emitting a big rectangle. This would let us avoid touching a lot of fragments twice which amounts to a lot of overdraw.

Comment 1

[Markus Stange [:mstange]]

It should be noted that we have both a non-scrolled background color and a scrolled background color for most pages. The non-scrolled background color is in the back and is what is shown during checkerboarding, when the scrolled background color is clipped to the display port and doesn't cover the whole window.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Does this still happen? Do we care?

Comment 3

[Nicolas Silva [:nical]]

I just looked at this in renderdoc and when rendering a github issue, we have 4 quads more or less the size of the screen that are fully occluded as far as I can tell (that is, looking at the view that shows the fragments that are rejected by the depth test with batching disabled).

IIRC, Dzmitry's tool that estimates the cost of depth-rejected primitives taught us that we pay on average 7% of the cost of a full screen rect in GPU time if it is completely depth rejected, which is not negligible for a full screen rect (not sure how much of that cost is memory bandwidth vs other things).

I think that we should care. Nothing blocking, but this is an area to look into when working on performance.

Comment 4

[Nicolas Silva [:nical]]

I count 5 full screen (or almost) occluded quads on this bugzilla page.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Worth looking again?

Comment 6

[Nicolas Silva [:nical]]

Picture caching makes things a bit better because the chrome tiles that are fully occluded are discarded without being drawn. We still get a lot of overdraw in the areas near the top (and the scroll bars? not sure what's going on there) from a glance at a renderdoc trace, we composite large rectangular tiles for these parts, most of which being z-rejected.

When tiles are rendered from scratch we also pay for clearing + drawing a solid background, but this cost is amortized by retaining the tiles and (hopefully) not invalidating all of the tiles every frame.

Wherever picture caching is disabled we still pay a few screen-fulls of z-rejected overdraw every frame.

Comment 7

[Glenn Watson [:gw]]

This is resolved now. WR will take the background color as the clear color where possible, and will occlude background tiles where possible.