I tried this on a Nexus 5X with M58 and the test seems to run at a smooth 60 fps.

Could you record a profiling trace[1] on a problematic phone? It should help us analyze this further.

[1] https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs

OK, I recorded a trace for ~10 sec on a HTC 10 which was running at 49-50 FPS for the whole duration: https://dl.dropboxusercontent.com/u/15217362/trace_htc10-50fps.zip

I also tested a Samsung Galaxy Tab S2 and it could run at 60 FPS, so it seems to depend on the device.

According to the trace graph, the device has a vsync period of slightly more than 20ms.  So 49 FPS appears to match the display's actual refresh rate.  If you are seeing this fluctuate, it is possible that the device has some kind of throttling mechanism (to save power, to reduce heat or something like that).

Re-triaging as a GPU scheduling issue.
CC'ing people who know more about mobile graphics.

It definitely looks janky at 50 FPS, and as I mentioned if I change orientation it briefly runs at ~58 FPS which looks perfectly smooth, then drops down to 50 FPS and looks janky again. So I am pretty sure the device really does have a display rate of 60 Hz.

I've also verified it's not running in any kind of battery saver mode, and the problem also still reproduces while charging. I checked the other apps and settings to look for anything that might be trying to throttle anything - doesn't seem to be anything there, as far as I can tell it's more or less a stock HTC 10 (albeit with an official update to Nougat 7). According to Construct 2 users, other devices are also affected, including the Galaxy S7.

Yeah, from that trace, android is ticking frames at ~20ms intervals. That's really odd and I've never seen that before.. I assume this is some misguided power saving "feature", especially if it comes and goes.

There is something else I don't understand. Looks like on the renderer compositor thread, the deadline comes immediately after begin frame. That should only affect latency, not throughput.

Looks like the scheduler switched from low latency mode to high latency mode at ~280ms in the trace. The scheduler has some heuristics for latency recovery but looks like they're not working. However, as you said that should only affect latency and not smoothness. Android is ticking us 20ms apart but also claiming that the interval is 16ms.

I can't repro the jankiness shown in https://www.youtube.com/watch?v=RGxxJeHbj10 on my Galaxy S7 SM-930U with 57.0.2987.74/MMB29M, nor on 56.0.2924.87, nor on 58.0.3021.0.  I always got 58-60fps.

According to file name, trace is taken on a htc10? Do you have the exact build fingerprint? It's at the very top of a bugreport, eg for pixel, it's something like:

Build fingerprint: 'google/sailfish/sailfish:7.1/NDE63N/3293322:user/release-keys'

I can repro the 50FPS on HTC 10/NRD90M on 52.0.2743.43 and 56.0.2924.87.  Not a regression in Chrome.  Might be a regression in the HTC 10 OS when it upgraded from M -> N.

Touching the screen improves the FPS to 60fps for a few seconds.  Seems like a touch-related power "optimization".

+Dan from the SurfaceFlinger team: Do you know if SurfaceFlinger can run at 50Hz sometimes for certain devices like the Galaxy S7 or HTC 10?

The Choreographer FrameCallback is begin called at 20ms intervals in the trace in comment #4.

Same framerate on https://play.google.com/store/apps/details?id=com.maxFPS which I assume is using GLSurfaceView directly.  Note my HTC 10 is at 5% battery, in case that changes anything.

The original report at https://www.scirra.com/forum/choppy-jerky-frame-skips-on-android_t186905 seems like a different issue based on the wide variety of devices and OS versions.  But we've not been able to repro any problem outside of the HTC 10.  I suspect there's something unusual about that developer's setup, for instance it could be a badly behaved background app they have installed on all their test devices.

So, WontFixing for now as it doesn't seem there's anything actionable here.  But, feel free to ask again another issue if you can get more repro details out of the original reporter or identify a Chrome-specific problem.

> +Dan from the SurfaceFlinger team: Do you know if SurfaceFlinger can run at 50Hz sometimes for certain devices like the Galaxy S7 or HTC 10?

OEMs usually don't tell anyone when they do this stuff in their forks.  It's optimization magic sauce.

My HTC 10 build fingerprint is:  'htc/pmeuhl_00401/htc_pmeuhl:7.0/NRD90M/857212.3:user/release-keys'

I can also confirm what aelias found that touching the screen restores smooth v-sync for a couple of seconds, then it drops back down.

I hadn't noticed this previously and my HTC 10 did recently get an M -> N update so I would not be surprised if HTC have hosed this. Maybe someone should tell HTC? :-\

I'm pretty sure HTC did it on purpose because it improves some battery benchmark.