Based on this I expect the following to be happening: 1. Scene build 2. Vsync, which advances the LastComposeTime in the vsync dispatcher 3. `WebRenderBridgeParent::MaybeGenerateFrame` runs which [advances](https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/gfx/layers/wr/WebRenderBridgeParent.cpp#2453) the APZ "current" sample time 4. `update_document` runs which samples from APZ [here](https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/gfx/wr/webrender/src/render_backend.rs#1553). Because the APZ frame delay is enabled, this actually returns values corresponding to the previous sample time (i.e. the vsync preceding the scene build). Nonetheless, I would expect this to provide updated scroll offsets to WR which should cause an actual frame build instead of bailing out with `frame_is_valid=true`. So why that's happening is an open question. But this will also advance the APZ animations "current" sample time, which is the LastComposeTime from step 2. 5. `update_document` runs again, samples from APZ again. This "current" sample time is the same as before, but the APZ animations were advanced at the end of step 4, so this will return different scroll offsets from what was produced in step 4. And it will *not* advance APZ animations any further, because the new sample time [hasn't changed](https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/gfx/layers/apz/src/AsyncPanZoomController.cpp#4045). 6. Vsync, which advances the LastComposeTime in the vsync dispatcher 7. `WebRenderBridgeParent::MaybeGenerateFrame` runs which again advances the APZ "current" sample time to the LastComposeTime in step 6. 8. Another `update_document` happens. Since step 5 didn't advance animations, the scroll offsets here will be the same as in step 5. And APZ animations will get advanced to the timestamp from step 6/7. Since this step doesn't produce new scroll offsets, it makes sense that WR will not repaint anything. I thought that if, in step 5, we prevent APZ from producing any scroll offsets at all (via the patch I sent :jrmuizel) then it would make step 8 render properly. But I guess we're still missing something there. Would be worth trying to confirm all this by logging the sample time passed to APZCTreeManager::SampleForWebRender and correlating it with the data posted previously. Would also be worth trying to answer the open question in step 4.
Bug 1630781 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Based on this I expect the following to be happening: 1. Scene build 2. Vsync, which advances the LastComposeTime in the vsync dispatcher 3. `WebRenderBridgeParent::MaybeGenerateFrame` runs which [advances](https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/gfx/layers/wr/WebRenderBridgeParent.cpp#2453) the APZ "current" sample time 4. `update_document` runs which samples from APZ [here](https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/gfx/wr/webrender/src/render_backend.rs#1553). Because the APZ frame delay is enabled, this actually returns values corresponding to the previous sample time (i.e. the vsync preceding the scene build). Nonetheless, I would expect this to provide updated scroll offsets to WR which should cause an actual frame build instead of bailing out with `frame_is_valid=true`. So why that's happening is an open question. But this will also advance the APZ animations to the "current" sample time, which is the LastComposeTime from step 2. 5. `update_document` runs again, samples from APZ again. This "current" sample time is the same as before, but the APZ animations were advanced at the end of step 4, so this will return different scroll offsets from what was produced in step 4. And it will *not* advance APZ animations any further, because the new sample time [hasn't changed](https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/gfx/layers/apz/src/AsyncPanZoomController.cpp#4045). 6. Vsync, which advances the LastComposeTime in the vsync dispatcher 7. `WebRenderBridgeParent::MaybeGenerateFrame` runs which again advances the APZ "current" sample time to the LastComposeTime in step 6. 8. Another `update_document` happens. Since step 5 didn't advance animations, the scroll offsets here will be the same as in step 5. And APZ animations will get advanced to the timestamp from step 6/7. Since this step doesn't produce new scroll offsets, it makes sense that WR will not repaint anything. I thought that if, in step 5, we prevent APZ from producing any scroll offsets at all (via the patch I sent :jrmuizel) then it would make step 8 render properly. But I guess we're still missing something there. Would be worth trying to confirm all this by logging the sample time passed to APZCTreeManager::SampleForWebRender and correlating it with the data posted previously. Would also be worth trying to answer the open question in step 4.