Scrolling YouTube has a lot of invalidation gfx.webrender.quality.force-disable-sacrificing-subpixel-aa=false
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox78 | --- | fixed |
People
(Reporter: jrmuizel, Assigned: gw)
References
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.
Assignee | ||
Comment 1•5 years ago
|
||
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 | ||
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
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.
Assignee | ||
Updated•4 years ago
|
Comment 4•4 years ago
|
||
bugherder |
Assignee | ||
Comment 5•4 years ago
|
||
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?
Assignee | ||
Comment 8•4 years ago
|
||
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.
Reporter | ||
Comment 9•4 years ago
|
||
It looks like this may cause some test failures: https://treeherder.mozilla.org/#/jobs?repo=try&revision=aa826a54f4444c00ee5638c4fe2e4dc52c74db55&selectedTaskRun=QQRhDTelTJWzwZ7JIl-CbQ-0
Reporter | ||
Comment 10•4 years ago
|
||
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
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
bugherder |
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Description
•