Closed Bug 1635610 Opened 3 months ago Closed 3 months ago

Scrolling YouTube has a lot of invalidation gfx.webrender.quality.force-disable-sacrificing-subpixel-aa=false

Categories

(Core :: Graphics: WebRender, defect)

defect

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox78 --- fixed

People

(Reporter: jrmuizel, Assigned: gw)

References

(Blocks 2 open bugs, Regressed 1 open bug)

Details

(Whiteboard: wr-planning)

Attachments

(3 files)

This shows up for me on Gen6 because I'm below the resolution threshold of 1920x1080.

If lower the threshold to 0 I see big improvements. Draw calls go from 35 -> 10, time on the renderer thread goes from 4.6ms down to 2ms and we are generally able to finish submitting our frame before window server is done its gpu work.

When we have a resolution <= 1920 x 1080, we set a flag that favors subpixel AA over performance.

To do this, we avoid creating a separate picture cache slice for different scroll roots, so that we can guarantee the subpixel AA rendering will all occur in the same slice. This causes more tile invalidations and rasterizations to occur.

The current implementation of this is very conservative (just since it's a first implementation). We can probably fix the majority of these issues by handling the common case (otherwise we stray too far in to FLB-style heuristics).

In the common case, where we can easily identify that the slices don't have text run(s) that overlap, we can create extra slices (as we do for high resolutions), knowing that this can't have any impact on whether any text runs receive subpixel AA.

There might be a couple of edge cases / complexities to deal with in implementing this, but that's the basic idea.

Assignee: nobody → gwatson
Whiteboard: wr-planning

Previously, any time a text run was encountered that was outside the
detected opaque backdrop of a picture cache, all subpixel AA would
get disabled for that surface.

Recently, we added support for conditional subpixel mode, where a
list of excluded rects can be provided (compositor surfaces) that
require a text run to disable subpixel AA.

This patch extends that, adding an inclusion rect to the conditional
subpixel mode. This allows subpixel AA to be enabled on any text
runs that are within the bounds of the detected opaque backdrop
for a picture cache.

Keywords: leave-open
Pushed by gwatson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d5eab5a42b3e
Part 1 - Improve situations where subpixel AA is enabled. r=nical
Attached image yt.png

With the attached patch, WR enables subpixel AA in more cases than it was previously able to.

I disabled the subpixel quality option (so that it creates slices as it does in hi-dpi mode), and tested on a small number of common pages.

For example, on the front page of youtube.com there are five distinct areas where text is rendered (see attached image).

In this table, Y means subpixel AA is enabled:

Edge Chrome WR (new) WR (old) Gecko
Region A - Y Y Y Y
Region B - - - - Y
Region C - - - - Y
Region D - - Y - Y
Region E Y Y Y Y Y

A few notes:

  • Gecko (non WR) uses subpixel AA everywhere, but at significant performance cost / complexity / power usage.
  • WR with this patch gets subpixel AA in most places, including sidebar (just not on search/sign-in).
  • WR gets subpixel in more places than both Chrome and Edge do.

It seems like in the cases I tested we get subpixel AA in more places than Edge/Chrome do. There will certainly be edge cases where that isn't true, which we can aim to improve on a case-by-case basis. There are also cases where we don't get subpixel AA as much as Gecko, but without implementing the expensive dual render technique that Gecko uses (which isn't compatible with OS compositors), we can't completely match that.

Given that, we could change the force-disable-sacrificing-subpixel-aa setting such that:

  • It defaults to always create slices for scroll roots (so <= 1920x1080 behaves the same as high resolution, with associated performance benefits)
  • We retain a config option (similar to force-disable-sacrificing-subpixel-aa) for users who really want to force subpixel AA at the cost of performance in more places, but it defaults to off for all resolutions.

We could enable that in nightly, and see how it goes. Jeff, Jessie, does that sound reasonable to you?

Flags: needinfo?(jmuizelaar)
Flags: needinfo?(jbonisteel)

Sure!

Flags: needinfo?(jbonisteel)

Yes!

Flags: needinfo?(jmuizelaar)

Part 1 of this patch enables subpixel AA in more cases when there
are multiple picture cache slices. Because of this, we can enable
extra picture cache slices by default, as a performance win for
the general case.

Users who want to force subpixel AA in more cases, at the cost of
performance can manually set the about:config value called
gfx.webrender.quality.force-subpixel-aa-where-possible.

For the record, it looks like the test machines with the following resolutions:
Windows: (1280x1024 + 1024x768)
Linux: 1600x1200
Mac: 1600x1200

Also the change to introduce the restriction didn't muck with the failing tests:
https://hg.mozilla.org/releases/mozilla-beta/rev/680eace9a704

Pushed by jmuizelaar@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2a23ec098a95
Enable per scroll root picture cache slices by default. r=jrmuizel,aosmond
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
You need to log in before you can comment on or make changes to this bug.