1614063 - VSync notifications on Android don't fire consistently under some circumstances

Status: RESOLVED INVALID

(GeckoView :: General, defect)

Description

[Markus Stange [:mstange]]

Steps to reproduce:

1. Install Firefox Preview Nightly from the Google Play Store.
2. Grab a profile from it, with "IPDL Background" on the thread list and the "IPC Messages" feature enabled.
3. Use the URL bar to navigate to some pages while profiling.
4. In the profile, select the IPDL Background thread and use the search filter to show only messages with the substring "VSync".

Expected results:
Between ObserveVsync and UnobserveVsync messages, there should be a consistent and unabating firing of Notify messages.

Actual results:
There are large gaps where no Notify messages are sent. The Java main thread is busy during those gaps.
Profile: https://perfht.ml/2tCVnon

I have a few questions:

• Is the Java main thread the source of our vsync messages? Can we observe vsync on a different thread?
• What is androidx.transition.CanvasUtils.runBlocking?

We cannot ever block the Java main thread if this impacts paints and composites because we're not getting vsync messages.

Comment 1

[Markus Stange [:mstange]]

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

• Is the Java main thread the source of our vsync messages?

It seems so! I can see org.mozilla.gecko.gfx.VsyncSource.doFrame being called in the Java Main thread in https://perfht.ml/3bnXjSC (under android.view.Choreographer$FrameDisplayEventReceiver.run).

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

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

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

• Is the Java main thread the source of our vsync messages?

It seems so! I can see org.mozilla.gecko.gfx.VsyncSource.doFrame being called in the Java Main thread in https://perfht.ml/3bnXjSC (under android.view.Choreographer$FrameDisplayEventReceiver.run).

Yeah, this is on the UI thread (or "Java main" thread). We usd to do it on be on a different thread, but it caused some issues with touch events and APZ (bug 1432019). I vaguely remember some concern about blocking, but it's generally unacceptable to block the UI thread on Android, so figured it would be ok.

It looks like Fenix is doing something silly to block the UI thread in this case, so we should figure that out with them.

Comment 3

[Markus Stange [:mstange]]

I've filed the Fenix bug as issue #8238.

Comment 4

[James Willcox (:snorp) ([e-mail]) (he/him)]

Closing this as there's nothing GV can do to stop the app from blocking the UI thread.