1380787 - fennec does not run rAF or rIC callbacks at 60fps unless screen is touched, part 2

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect, P5)

Description

[Kartikaya Gupta (email:[e-mail])]

+++ This bug was initially created as a clone of Bug #1378966 +++

STR (from original bug, with modifications):

1. Open this site in fennec https://timer-flood.glitch.me/
2. Do nothing and just wait for the numbers to stabilize
3. Observe that they are at less than 60fps
4. Tap the screen somewhere
5. Observe that the rAF and rIC numbers increase to ~60 fps for a short time after tapping

I have no explanation for why tapping the screen would allow us to run requestAnimationFrame faster.

I don't observe this behavior on desktop, so filing under fennec for now.

Bug 1378966 has some investigation and a patch which helped somewhat but didn't fix the issue entirely.

Comment 1

[Randall Barker [:rbarker]]

The patch for Bug 1378966 has greatly improved the rAF on my test device. I previously reported it was fluctuating between 57-60Hz. That was with a debug build. With an optimized build it seems to bee much more in line with 60Hz. The rIC how ever did not change even with the optimized build and still runs around 40Hz. Tapping on the screen will bring the rIC up to 60Hz.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

I believe our idle dispatch does some kind of prediction of time-till-next-frame.  If we are firing refresh driver too fast, then perhaps that is confusing the idle dispatch code.  Bug 1378966 comment 12 claims its firing at 80fps.

Olli, what do you think?

Comment 3

[Kartikaya Gupta (email:[e-mail])]

With the patch on bug 1378966 I don't think it should be firing at 80fps any more. (As per the comment you referenced, once we stop double-incrementing the mPendingTransaction counter, we should stop setting mWaitingForTransaction to true, which means the DidComposite messages should stop ticking the refresh driver - therefore only vsync will tick the refresh driver, at 60Hz.)

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

Thanks.  I misunderstood.  Perhaps we just really don't have that much idle time.  Maybe a new profile is in order.

Snorp, can you take a new profile with your setup when you get a chance?  (I'm leaving for PTO shortly...)

Comment 5

[Randall Barker [:rbarker]]

(In reply to Ben Kelly [reviewing, but slowly][:bkelly] from comment #4)
> Thanks.  I misunderstood.  Perhaps we just really don't have that much idle
> time.  Maybe a new profile is in order.
> 

Not having enough idle time does not explain why rIC goes to 60Hz when tapping on the screen.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

I can't think of any reason why rIC would change when tapping.
Do we have some code using user-interaction-active for something relevant?

Comment 7

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

Attachment: New profile with m-c from today

View it on perf-html.io directly here: https://perf-html.io/public/287ac1d12b7951cd8ad5d6c89733865078b5b36a

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Seems like ~60% of the time in the main thread is idle. I don't know how rIC is triggered so I don't know what rate is expected under these circumstances.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

If the next refresh driver tick or next timer is about to fire soon, rIC won't be called.
You may want to play with idle_queue.min_period and layout.idle_period.time_limit.


There isn't any requirement that rIC should get called 60hz. In fact, rIC callback may never get called.

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

The profile in comment 7 shows 16ms to 18ms rasterizes.  For example:

  https://perfht.ml/2gQnolr

That seems pretty bad to me.  I mean, this site is not doing much actual work.  Is there a graphics issue here?

Comment 11

[Ben Kelly [:bkelly, not reviewing]]

Or are we over-drawing for some reason?

Comment 12

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

(In reply to Ben Kelly [PTO, back July 24][:bkelly] from comment #10)
> The profile in comment 7 shows 16ms to 18ms rasterizes.  For example:
> 
>   https://perfht.ml/2gQnolr
> 
> That seems pretty bad to me.  I mean, this site is not doing much actual
> work.  Is there a graphics issue here?

I agree, that seems pretty terrible. IIRC, the paint time is mostly in gfxUtils::DrawPixelSnapped() which is probably doing scaling. Jeff, any insight into the profile here?

Comment 13

[Firefox Bug Husbandry Bot]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

Comment 14

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.