Created attachment 319637 [details]
The attached testcase is essentially attachment 316551 [details] + some regular calls to requestAnimationFrame(). After r220261, the flickering is gone, but we still see some "big jumps" when scrolling the frame.
This issue disappears if we remove these requestAnimationFrame() calls or reduce their frequency. It looks like these requestAnimationFrame might cause some out-of-sync scroll coordinates between the web and UI process.
Created attachment 326761 [details]
This testcase relies on a more standard use of requestAnimationFrame.
I did a quick debugging of this and the trace for requestAnimationFrame is something like:
where RemoteLayerTreeDrawingArea::flushLayers commit the scrolling state and is actually also called when we perform async scrolling on iOS. So I don't see anything abnormal. Maybe requestAnimationFrame should not commit the scrolling state and let that work be done by the async scrolling code to avoid conflicts?
Created attachment 326879 [details]
This patch is a quick dirty hack to force a delayed flush when RemoteLayerTreeDrawingArea::scheduleCompositingLayerFlush is caused by a requestAnimationFrame call. As you can see, it avoids big jumps of the fixed element in the testcase. I wonder whether we should do something like that when user scrolling is happening... @Simon: WDYT?
I don't get why that's the right approach to fix this bug. Would need to analyze further.