Improve how dirty image detection works in webrender
Categories
(Core :: Graphics: WebRender, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox73 | --- | fixed |
People
(Reporter: gw, Assigned: gw)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
-
The existing code to detect if an image is dirty fails in some
cases. For external images, they were not being added to the
list of dirty images when update was called. Further, since
the dirty image keys hash set was cleared each frame, it was
possible for an image to become dirty, but this detection to be
missed if it is not queried until a subsequent frame (due to
it being off-screen.Instead, each image template has a generation identifier that
is incremented whenever an image template is updated. The picture
caching code stores the generation of the image key when it was
rasterized, and compares that to the current image key generation
when comparing dependencies. This fixes both cases above. -
Remove the is_cacheable logic that was previously used to
invalidate picture cache tiles for external images. This would
result in picture cache images that intersect with videos being
invalidated every frame unconditionally. However, this code path
is no longer required, due to the change above. By relying on
the true image dirty check, we can skip invalidating tiles
affected by video if the video frame has not advanced (e.g. it
is paused, or advancing at a lower frame rate than we are
currently compositing at).
Comment 3•5 years ago
|
||
bugherder |
Comment 4•5 years ago
|
||
Backed out changeset 93ccc760c4dd (Bug 1599965) for causing wrench bustage on central CLOSED TREE a=backout
Updated•5 years ago
|
Assignee | ||
Comment 6•5 years ago
|
||
I don't understand how that failure is caused by this patch - it seems like some kind of compile error in a dependency that is unrelated to this change? It also passed on a try run on that configuration.
I'll take a closer look tomorrow and see if I can work out what's going on.
Assignee | ||
Comment 7•5 years ago
|
||
(this is the try run with this patch which seems to pass on that failing wrench platform - https://treeherder.mozilla.org/#/jobs?repo=try&revision=05d9b43469e8f6d0d9acc04b60f305f8392b3202&selectedJob=278974255)
Assignee | ||
Comment 8•5 years ago
|
||
I suspect the problem may actually be caused by / related to https://bugzilla.mozilla.org/show_bug.cgi?id=1595218 which landed recently?
Updated•5 years ago
|
Description
•