1598972 - Opaque gradients are considered transparent

Status: RESOLVED FIXED

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

Description

[Markus Stange [:mstange]]

Attachment: opaque-gradient-background.html

Steps to reproduce:

1. Load the attached testcase.
2. Enable gpu-time-queries and the WebRender profiler overlay.

Expected results:
You should only see gradient painting in the GPU frames view.

Actual results:
You see both Solid color painting and gradient painting.

Alternatively, you can make a testcase that has lots of opaque gradients on top of each other. Only the top one should be painted, but currently you can see frame times get slower as you add gradients.

Comment 1

[Jessie [:jbonisteel] pls NI]

Hey Markus - when do you think we should fix this?

Comment 2

[Markus Stange [:mstange]]

Attachment: opaque-gradient-background.html

(fixing a typo in the testcase)

Comment 3

[Markus Stange [:mstange]]

(In reply to Jessie [:jbonisteel] plz needinfo from comment #1)

Hey Markus - when do you think we should fix this?

It's not hugely important to fix, but it'll help performance on web pages that use gradient backgrounds. It should be an easy one-off patch - maybe even a good wr-intro bug. So it's not urgent but should have good payoff for the time investment.

Implementation note: Non-WebRender painting marks gradients as opaque if all color stops are opaque, see nsStyleImage::IsOpaque() which calls into StyleGradient::IsOpaque(). I don't know where the corresponding code in WebRender is.

Comment 4

[Jessie [:jbonisteel] pls NI]

Jim, just pinging you as this is another task we can talk about as something to take a look at

Comment 5

[Jim Blandy :jimb]

Sure, I'll give it a shot.

Comment 6

[Jim Blandy :jimb]

Markus, instead of addressing this in WebRender, would it make sense to detect the situation further upstream? For example, it seems to me that nsCanvasFrame::BuildDisplayList has enough information to recognize that some of the backgrounds are redundant.

Comment 7

[Markus Stange [:mstange]]

We can apply some optimizations upstream, but not all. If we cull the hidden background color item at the Gecko level, WebRender may still decide to do extra work behind the gradient, for example it might unnecessarily clear a tile before drawing the gradient into it. Or it might treat the tile that contains the gradient as a transparent tile, and then allocate and draw tiles for the browser background because it thinks that stuff from behind the website might show through.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

Not going to make it into 75

Comment 9

[Jessie [:jbonisteel] pls NI]

Hey Jim, let's see the patch! :)

Comment 10

[Jim Blandy :jimb]

The performance problem appears to have been fixed by bug 1621390. The profiler no longer shows any time spent doing solid color painting.

That patch doesn't allow opaque gradients to serve as backdrops, but gw says there that this is a rare case that isn't worth fixing. The reproduction instructions in this bug don't suggest otherwise, so I think we can close it.

Comment 11

[Jim Blandy :jimb]

Attachment: Bug 1598972: Consider gradients as tile backdrops.

The fix for bug 1621390 extended the tile backdrop computation to recognize
images. This patch extends that to consider linear gradients as potential
backdrops as well.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c504d0a26475
Consider gradients as tile backdrops. r=gw

Comment 13

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/c504d0a26475