Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upDelay reftest screenshot while WR frame is rendering #25822
Conversation
highfive
commented
Feb 21, 2020
|
Heads up! This PR modifies the following files:
|
|
@bors-servo try=wpt |
Delay reftest screenshot while WR frame is rendering
|
I'm going to retry a bunch of WPT tests and see if this affects #24726 at all. |
|
|
This comment was marked as outdated.
This comment was marked as outdated.
|
@bors-servo try=wpt |
Delay reftest screenshot while WR frame is rendering
|
|
|
@bors-servo try=wpt |
Delay reftest screenshot while WR frame is rendering
|
|
|
https://community-tc.services.mozilla.com/tasks/groups/RbZ--54CQYGFmjcK--pc6w is a try run that runs the linux WPT tasks 30 times each and did not report a single instance of #24627. |
|
@bors-servo r=emilio on Matrix |
|
|
|
@bors-servo p=10 |
|
|
jdm commentedFeb 21, 2020
•
edited
This PR addresses the theory that #24726 occurs when WR is performing an async frame render and the reftest screenshot decides it's time to synchronously read the framebuffer. If there have not been any completed frames rendered yet, that would yield the page background colour.
The changes in this PR introduce an additional layer of synchronization - the compositor stores an AtomicBool value that indicates whether we know that a WR frame has started rendering, which is set to true when an IPC request from layout that submits a new display list is received. This bool is set to false when WR notifies us that a frame has been rendered. The screenshot code refuses to take a screenshot if the bool is true, causing us to delay taking a screenshot until there is no frame pending.