Many Blink layout tests today use event sender to inject gesture events into Blink. For example:
eventSender.gestureScrollBegin(100.1, 300.2);
eventSender.gestureScrollUpdate(-20.5, -10.2);
eventSender.gestureScrollEnd(0, 0);
This injects events directly into Blink, bypassing the threaded compositor-side scrolling path. Instead, these tests should inject non-gesture input events lower down in the stack (in the browser process). e.g.:
chrome.gpuBenchmarking.smoothScrollBy(
2,
() => { console.log("DONE"),
100.1,
300.2,
MOUSE_INPUT,
'down');
This bug tracks converting layout tests from the former to the latter. As a start, I looked for all tests in LayoutTests/ that use eventSender for gesture scrolls using:
git grep eventSender.gestureScroll | cut -d' ' -f1 | uniq
Which points out 53 tests. We should go through this list, narrow it down to high-value tests for the purpose of scrollilng, and convert those to use gpuBenchmarking. If the list is too large we can split the work out between multiple people.
Also look through event sender for other types of methods which may miss valuable scrolling tests (e.g. wheel?)
Comment 1 by bokan@chromium.org
, May 24 2018By the way, I asked Ella to add resources/gesture-util.js in a recent CL. We should encode some of the common patterns we use there and share them across scrolling/gesture tests. e.g. this pattern has been used in many tests: function waitForScrollAndCheck() { const MAX_FRAME = 500; return new Promise((resolve, reject) => { function tick(frames) { // We requestAnimationFrame either for 500 frames or until scrollable scrolls. if (frames >= MAX_FRAME || scrollable.scrollTop > 0) resolve(); else requestAnimationFrame(tick.bind(this, frames + 1)); } tick(0); }); }