Closed Bug 1558106 Opened 2 years ago Closed 2 years ago

Support picture caching for multiple scroll roots.


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




Tracking Status
firefox69 --- fixed


(Reporter: gw, Assigned: gw)


(Blocks 1 open bug)



(1 file)

No description provided.

This patch implements the majority of the planned picture caching
improvements. It supports most of the functionality required to
(as a follow up) support OS compositor integration. It also improves
on the robustness and functionality of the previous picture caching

There are some expected temporary performance regressions in
some cases (such as content that is constantly invalidating) and
during initial page render when many render targets must be drawn
to. These performance regressions will be resolved in follow up
commits by supporting multi-resolution tiles.

The scene is split into a number of slices, determined by the scroll
root of each primitive, which can be found by the primitive's
spatial node indices. If a scene contains too many slices, then
picture caching is disabled on the page, to avoid excessive texture
memory usage, and rendering falls back to rasterizing each frame.

The specific changes in this patch are:
* Support tile caches for multiple scroll roots, allowing the
entire page (including fixed divs and the main UI bar) to be
cached in most cases, in addition to the main content.
* Remove requirement to read tiles back from the framebuffer.
Instead, they are drawn into the picture cache target tiles,
and blitted to the screen. This is slightly slower than the
existing picture caching when content is constantly changing,
however this cost will disappear / become irrelevant when
the OS compositor integration work is complete.
* Switch picture cache render targets to be nearest sampled (they
are always rendered 1:1) and support depth buffer targets.
* Make use of the external scroll offset support to allow removal
of the primitive correlation hacks in the previous picture
caching implementation. Also allows storing of primitive
dependencies in picture space rather than world space, which
reduces floating point inaccuracies.
* Determine if each tile and picture cache can be considered
opaque. This is used to determine whether subpixel AA text
rendering is available on a slice, and for rendering optimizations
related to disabling blending and/or tile clears.
* Use the clip chain instance results from the recent visibility pass
work to determine clip chain dependencies. This results in fewer
clip item dependencies in tiles, which is faster to check validity
and reduces redundant invalidations.
* Remove extra overhead during batching related to batch lists,
and region iteration, as they are no longer required.
* Support PrimitiveVisibilityMask during batching. This allows a
single traversal of a picture (surface) root during batching to
efficiently construct multiple alpha batcher objects (typically
one per invalida tile).
* Picture caching is now handled implicitly by WR, depending on
the content of the scene. There is no requirement for client
code to manually select which stacking context should be cached.
* Simplify how clip chain / transform dependencies are tracked by
picture cache tiles.
* Support pushing / popping enclosing clip chain roots without
the need for a stacking context / picture in some cases. This
simplifies the logic to split the scene into multiple slices.

The main remaining work in this area is (a) extend the code to
optionally provide each slice as an input to the OS compositor
rather than drawing the tiles in WR, and (b) support multi-resolution
tiles so that we reduce the draw call, batching and render target
overhead in cases where much of the page content is changing.

Blocks: 1536360
Priority: -- → P3

I saw your messages on IRC about the reftest-resolution reftest failures, so I took your try push at and applied my patches from bug 1557970 on top and repushed. Hopefully that will fix it. Here's the new push:

Assignee: nobody → gwatson
Pushed by
Support picture caching for multiple scroll roots. r=kvark

From what I could tell the try runs looked good, and I didn't notice any issues after a reasonable amount of manual testing.

However, please feel free to back out if it lands and causes any issues overnight - I can investigate anything that comes up tomorrow.

Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
Regressions: 1559284
Regressions: 1559354
Regressions: 1559328
Regressions: 1559488
Regressions: 1559535
Regressions: 1559879
Regressions: 1560499
Regressions: 1560853
Regressions: 1563609
See Also: → 1520096
Regressed by: 1561215
No longer regressed by: 1561215
Regressions: 1561215
Regressions: 1566069
Regressions: 1566901
Regressions: 1562370
Regressions: 1567472
No longer regressions: 1562370
Regressions: 1566099
Blocks: 1538669
You need to log in before you can comment on or make changes to this bug.