Low FPS in C2 games is more crippling than it should be?

Problems Detected

GPU rasterization is whitelisted on N4, N5, N7 and Moto X: 362779

Disabled Features: gpu_rasterization

Additional GPU rasterization whitelist for field trial: 380694

Disabled Features: gpu_rasterization_field_trial

Some drivers are unable to reset the D3D device in the GPU process sandbox

Applied Workarounds: exit_on_context_lost

TexSubImage2D() is faster for full uploads on ANGLE

Applied Workarounds: texsubimage2d_faster_than_teximage2d

Clear uniforms before first program use on all platforms: 124764, 349137

Applied Workarounds: clear_uniforms_before_first_program_use

Threaded rasterization has not been enabled or is not supported by the current system.

Disabled Features: threaded_rasterization

Seems like 30fps is pretty playable. Maybe not ideal but certainly you should be able to play a game at 30 fps. 12 fps .. now that's unplayable.

Ashley fair enough, but it will probably need fine-tuning.

— Did you try my demo with GPU lag?

OK, back to the original issue - as a refresher, basically we've noticed that some lag is worse than other lag.

I've done some datalogging in three settings: CPU lag in the lag demo already provided, GPU lag in the same demo, and my game Airscape: The Fall of Gravity. At 30fps, here's what I noticed purely based on 'feel':

CPU lag: Felt perfectly fine, exactly what 30fps should be.

GPU lag: definite weirdness

Airscape: Absolutely horrible to control, nightmarish. Felt more like 5fps than 30fps.

Here are the dt logs I've made: [dt logged every tick]

CPU lag: very little deviation between dt

GPU lag: a fair bit of deviation between dt

Airscape: a LOT of deviation between dt

Ashley hopefully you can do something with this. There's definitely evidence here that something's wrong.

Everyone else, I've attached an updated lag test that you can use to test on your own machines. Bonus points for attaching to your games ( Aurel I'm looking at you )

Yep, CPU lag causes frame skipping but no noticeable difference in gameplay. GPU lag causes frame skipping and significant input delay rendering the game unplayable.

Yeah, well as you mentioned the disadvantage of a cap like 0.02 is a few seconds of lower framerate will run the game in to slow-mo for a few moments, which is disorientating for the player - kind of like randomly varying the timescale during gameplay. I'm not convinced that's a better solution. I think we want to aim for a value that just cuts off the spikes.

I think the game slowing down a little bit is far LESS disorienting (especially since every gamer ever is totally aware of and used to it) than severe input lag, skipping frames, and missing collisions, don't you?

I think we would be better off with finding solutions to implement easily ingame setting to offer the better experience for the player first (more precise graphical options, sure we have the low quality combined with The set canvas size, but I think there are maybe other ways to reduce that fps graphical drop) rather than making sure that variation of fps is not as hard for the player (since in that case I would assume cpu lag is stable, while gpu lag is varying like crazy).

Could be just my opinion but lower fps in a long term basically means no go anyway so we should more make sure that we can alter the graphics as needed, or better, the player can alter them himself to have the experience he prefers.

Okay, CPU lag on 30 fps isn't very noticable. GPU lag on 30 fps on the other hand destroys the gameplay with uneven lag spikes.

CPU lag:

https://dl.dropboxusercontent.com/u/705 ... gCPU30.txt

GPU lag:

https://dl.dropboxusercontent.com/u/705 ... gGPU30.txt

I think the Airscape log confirms my theory. Part of it has a dt sequence with these measurements:

31ms, 25ms, 41ms, 20ms, 31ms, 19ms, 35ms

There is variation from 19ms to 41ms - over double. This is really uneven frame scheduling and probably explains why it looks so bad, it's a totally unpredictable framerate frequency. I would expect frame-by-frame the actual CPU/GPU workloads are almost identical, unless you have significantly intensive events coded to run every other frame or every N frames. Assuming even workloads for each frame, this is probably bad scheduling by the browser.

At 37 FPS each frame is probably taking about 27ms to process, while the screen is drawn every 16.7 ms. If I write out how this is being scheduled...

Vsync 1: 16.7ms (skip)

Vsync 2: 33.3ms (render frame 1)

Vsync 3: 50ms (skip)

Vsync 4: 66.7ms (render frame 2)

Vsync 5: 83.3ms (skip)

Vsync 6: 100ms (render frame 3)

Vsync 7: 116.7ms (render frame 4)

Vsync 8: 133.3ms (skip)

Vsync 9: 150ms (render frame 5)

Vsync 10: 166.7ms (render frame 6)

Vsync 11: 183.3ms (skip)

Vsync 12: 200ms (skip)

Vsync 13: 216.7ms (render frame 7)

See how it's alternating between rendering two adjacent frames 16ms apart (e.g. render frames 3 + 4) and skipping two adjacent frames (e.g. render frames 6 and 7, which end up falling about 50ms apart!). No wonder it looks bad, that's like switching between 60 FPS and 20 FPS every few frames.

This needs to be solved on the browser side, I think. It looks like when each frame takes longer than a Vsync period to process then it starts aliasing really badly against the refresh rate. The only sensible alternative is to have the browser drop it right down to 30 FPS, which is a lower rate but at least looks predictable. I'll see if I can make a demo and file a bug report for Chrome...

Is there any ways to lock the max framerate? Low framerate is better than unpredictable play.

Actually maybe I was wrong:

http://www.scirra.com/labs/bugs/fpstest.html

In this minimal demo on my laptop dt is still pretty stable even after throttling it to ~45FPS. There was a bigger variation on Android though. Maybe it's system specific.

For me.

Before Throttle:

After Throttle:

FYI.

I'm not getting huge variation in Ashley 's demo (It's around what — got), how exactly is that demo trying to throttle? If it's just spawning a lot of objects with Sine motion, it's probably CPU lag more than GPU lag.

I'm pretty sure fillrate is the limitation that tends to cause these huge inconsistencies, since reducing the window size *always* helps with it.

That demo does a CPU-side throttling, it just wastes CPU time to hit 45 FPS. It's a bit weird, it looks juddery but relatively smooth in Chrome stable, but in Canary when throttled it seems to look even worse.

20-24ms isn't a very big range in dt, it's probably normal. The Airscape log had a much bigger variation (19-41ms).

Yep, totally agree. The problem definitely lies on the graphics side. Are you still sure it's a Chrome issue?

interesting investigation, i have been wondering this same thing long ago...