Page MenuHomePhabricator

Bug 1606251 - Fix invalidation for elements with inflation factors.
ClosedPublic

Authored by gw on Jan 30 2020, 5:44 AM.

Diff Detail

Repository
rMOZILLACENTRAL mozilla-central
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

gw created this revision.Jan 30 2020, 5:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 30 2020, 5:44 AM
phab-bot requested review of this revision.Jan 30 2020, 5:45 AM
phab-bot changed the visibility from "Custom Policy" to "Public (No Login Required)".
phab-bot changed the edit policy from "Custom Policy" to "Restricted Project (Project)".
phab-bot removed a project: Restricted Project.
kvark requested changes to this revision.Jan 30 2020, 8:01 AM

Patch looks reasonable, just one question about the approach

gfx/wr/webrender/src/picture.rs
2344–2374

I find it unexpected that we'd need to iterate all the surfaces in the stack here. If a nested surface is inflated, wouldn't it be taken into account by the relevant parent surface, and therefore the surface corresponding to the tile cache space (which is the only one surface I'd expect this code to check).

This revision now requires changes to proceed.Jan 30 2020, 8:01 AM
gw added inline comments.Jan 30 2020, 8:14 AM
gfx/wr/webrender/src/picture.rs
2344–2374

Although the surface is inflated, it's not detected as dirty because the parameters of the filter op in the picture haven't changed, only the content in the child primitives.

If we were to detect / propagate the dirtiness of a child primitive up to consider the filter picture itself dirty, then we'd be dirtying a potentially much larger region than we need to (the entire picture, rather than just the inflated portion of the child surface that was actually invalidated).

When I implement child picture caching, I think handling this will probably be quite a bit simpler, since we'll be storing dependencies on each child picture, rather than at the tile cache, and it should be simpler to propagate up dirty rects.

kvark accepted this revision.Jan 30 2020, 9:30 AM
kvark added inline comments.
gfx/wr/webrender/src/picture.rs
2344–2374

I think I get it now. We are not talking about propagation of surface bounds - this is already in place and just fine. We are talking about propagation of the primitive rectangle specifically through the surfaces here.

Wouldn't this be a concern for performance? The dependency updates are now O(surface_tree_depth * num_primitives), which could be heavy.

This revision is now accepted and ready to land.Jan 30 2020, 9:30 AM
gw added inline comments.Jan 30 2020, 9:44 AM
gfx/wr/webrender/src/picture.rs
2344–2374

It's potentially a concern for performance - but this branch only runs when the primitive exists on a different surface, which is fairly rare (and the depth of the surface stack is typically quite small). Hopefully it's ok!