This bug is created based on :mattwoodrow's mail. -------------------------- One other interesting bit is that the first frame of scrolling shows us moving the scrollbar thumb, but not the page content. Not sure why that is, or if it's related (could we be one frame behind for the scrolled content for the entire scroll?). The other possibility is that we got the layer tree updated message after sampling (5ms later according to the log) and ended up putting that new content into the same screen presentation

I used VLC media player for frame by frame video playback.

attachment 9003087 [details] seems to use Windows 10 Video Capture Tool by pressing Win+G.

I also confirmed the problem. The video was captured by Win10 capture tool by pressing Win+G.

The log was taken when attachment 9003089 [details] was captured with attachment 9003090 [details] [diff] [review].

In attachment 9003092 [details], when scrollbar thumb had [ 1 0 0 0 ; 0 1 0 0 ; 0 0 1 0 ; 0 4.98831 0 1 ] scroll node was "id ExternalScrollId(2, PipelineId(1, 6)) origin (0,-0.33120728)". It might be related to the problem.

(In reply to Sotaro Ikeda [:sotaro] from comment #4) > Created attachment 9003089 [details] > another captured video > > I also confirmed the problem. The video was captured by Win10 capture tool > by pressing Win+G. Hmm, Win10 Game DVR seemed not good for capturing, since it seemed to drop frames even when 60fps was set.

In APZCTreeManager::SampleForWebRender(), content scroll and thumb scroll used different EffectiveScrollOffset values. AsyncPanZoomController::AdvanceAnimations() was called after content scroll offset calculation and then calculated thumb scroll. Within AsyncPanZoomController::AdvanceAnimations(), AsyncPanZoomController::SampleCompositedAsyncTransform() was called. And it updated EffectiveScrollOffset values.

(In reply to Sotaro Ikeda [:sotaro PTO 31/Aug-7/Sep] from comment #9) > In APZCTreeManager::SampleForWebRender(), content scroll and thumb scroll > used different EffectiveScrollOffset values. > AsyncPanZoomController::AdvanceAnimations() was called after content scroll > offset calculation and then calculated thumb scroll. It could happen when "apz.frame_delay.enabled:true" is set.

rough diagram related to apz and WebRender

(In reply to Sotaro Ikeda [:sotaro PTO 31/Aug-7/Sep] from comment #9) > In APZCTreeManager::SampleForWebRender(), content scroll and thumb scroll > used different EffectiveScrollOffset values. > AsyncPanZoomController::AdvanceAnimations() was called after content scroll > offset calculation and then calculated thumb scroll. > > Within AsyncPanZoomController::AdvanceAnimations(), > AsyncPanZoomController::SampleCompositedAsyncTransform() was called. And it > updated EffectiveScrollOffset values. Thanks, this analysis makes the problem really clear! AsyncCompositionManager does things in this order: - sample transforms for scrollable layers and scroll thumb layers - advance animations SampleForWebRender does things in this order: - sample transforms for scrollable layers - advance animations - sample transforms for scroll thumb layers With the APZ frame delay enabled, the "advance animations" step rolls over the effective scroll offset from its old value to its new value, so it matters whether we sample a transform before or after it.

(Kats, I flagged you because you know this code best and this is an easy review, but let me know if I should redirect.)

Comment on attachment 9005707 [details] Bug 1485314 - Only advance animations in SampleForWebRender() after all async transforms have been sampled. r=kats Kartikaya Gupta (email:kats@mozilla.com) (parental leave) has approved the revision.

Pushed by bballo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/254a11648e89 Only advance animations in SampleForWebRender() after all async transforms have been sampled. r=kats