1675899 - The frame delay mechanism is largely ineffective on Android

Status: NEW

(Core :: Panning and Zooming, defect, P3)

Description

[Markus Stange [:mstange]]

Attachment: screen recording

Steps to reproduce:

1. Load attachment 9186418 [details] on Android.
2. Scroll up and down by panning (no flings).

Expected results:
The red circle should always stay centered in the black border.

Actual results:
The red circle jitters up and down during the pan. See the attached screen recording.

Comment 1

[Markus Stange [:mstange]]

Profile: https://share.firefox.dev/32hpQGI

There's a race here, between the vsync notification that causes the content paint, and the RequestContentRepaint message that updates the scroll position in content.

On Android, both the touch event and the vsync notification originate on the Java UI thread, and their timing is aligned. Android fires the touch event just before it calls the vsync callback. However, what happens afterwards is different:
The touch event is processed by APZ on the UI thread, then a runnable is dispatched to the compositor thread ("repaint thread"), and then a regular-priority IPC message is sent via PAPZ to the content process main thread.
The vsync notification is redirected to the PBackground thread and sent to the content process main thread via high-priority IPC message through PVSync, which is a sub-protocol of PBackground.

So, two hops each, via different event queues, and with different priorities. In the profile, the IPC markers indicate that the RequestContentRepaint call usually arrives first, but it has to wait for vsync anyway because vsync is higher priority. Or maybe PBackground has an extra thread hop in the content process as well, and that's what causes the extra delay, I'm not sure about that.

As a result, nothing guarantees that the updated scroll position arrives in content before the content paint happens.

Comment 2

[Markus Stange [:mstange]]

Here's one way we could guarantee an ordering:

• We could make vsync take the same path as RequestContentRepaint, sending it to the compositor thread first and then to the content process via a sub-protocol of PCompositorBridge. That way the two pieces of information always go through the same queues and there's no re-ordering.
• And we should make RequestContentRepaint a high-priority IPC message so that it doesn't get reordered behind the vsync notification.

Comment 3

[Botond Ballo [:botond]]

(In reply to Markus Stange [:mstange] from comment #2)

• And we should make RequestContentRepaint a high-priority IPC message so that it doesn't get reordered behind the vsync notification.

This part is being done in bug 1730998.