Closed Bug 1598972 Opened 6 months ago Closed 23 days ago

Opaque gradients are considered transparent

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox78 --- fixed

People

(Reporter: mstange, Assigned: jimb)

References

(Blocks 4 open bugs)

Details

Attachments

(2 files, 1 obsolete file)

Attached file opaque-gradient-background.html (obsolete) —

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.

Blocks: wr-73
Priority: -- → P3
Blocks: wr-74
No longer blocks: wr-73

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

Flags: needinfo?(mstange)

(fixing a typo in the testcase)

Attachment #9111101 - Attachment is obsolete: true

(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.

Blocks: wr-intro
Flags: needinfo?(mstange)
Blocks: 1613404
Blocks: wr-75
No longer blocks: wr-74

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

Flags: needinfo?(jimb)

Sure, I'll give it a shot.

Assignee: nobody → jimb
Flags: needinfo?(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.

Flags: needinfo?(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.

Flags: needinfo?(mstange)

Not going to make it into 75

Blocks: wr-76
No longer blocks: wr-75
Blocks: wr-77
No longer blocks: wr-76

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

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.

See Also: → 1621390

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.

Attachment #9139627 - Attachment description: Bug 1598972: Consider linear gradients as tile backdrops. → Bug 1598972: Consider gradients as tile backdrops.
Pushed by jblandy@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c504d0a26475
Consider gradients as tile backdrops. r=gw
Status: NEW → RESOLVED
Closed: 23 days ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
You need to log in before you can comment on or make changes to this bug.