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

Here is an example showing that low or normal frame rate doesn't solve jerkiness in non webgl canvas. Maybe that's just how we need to expect non accelerated canvas to perform?

I shift the rendering/window size in the video going from big to small. At the smallest it runs ~40fps but is the same amount of jerkiness as ~15fp

Another thing I experienced, that is not related directly, but is still graphic and performances related, is that a fullscreen game will be far more unstable fps wise than without being fullscreen, buuuuuuut I tested that on a computer with a 4 years old graphic driver, so I would think this is not useful in any way retrospectively. (Just to say, that without webGL, scaling the game seems to be more intensive, it was hardware accelerated as far as my browser said)

Colludium - Are you making a game on a phone?

I have an average laptop that I test my stuff on (i5, integrated graphics, 4 gigs o ram, etc). I am developing a game for pc and wi u and I run 1200 physics objects at a time. I use a custom sleeping system that allows my game to have 20,000 physics objects in a level, and 100s of compound characters (12+ sprites each) with overlapping checks on all of the characters every tick. I even have physics enabled particle systems because I can. I literally have no fps problems and have no need for that many objects, so I am set. I am curious how creating one object or performing more than one collision check per tick can cause lag. It doesn't make sense.

However, I have noticed as the OP stated that the game looks perceptibly different at 40fps instead of 60fps

Aphrodite - are you testing full screen in a browser or are you exporting the object? I have never noticed a difference between full screen and small screen unless you are upscalling via high quality and then that is just a function of how many pixels you have to draw each frame. (if you have a monitor that is 2000,2000 and you have 8 layers that force own texture... well, that is alot of stuff to render).

Ruskul, - I'm developing for desktop - browser and Node. This jittering is usually very slight and manifests as a momentary hesitation, but to my eyes it stands out very pronounced indeed.

I've just posted a demo capx in the other thread here.

Aphrodite - are you testing full screen in a browser or are you exporting the object? I have never noticed a difference between full screen and small screen unless you are upscalling via high quality and then that is just a function of how many pixels you have to draw each frame. (if you have a monitor that is 2000,2000 and you have 8 layers that force own texture... well, that is alot of stuff to render).

Was not my game, I guess it was the default settings aka high quality.

Another thing I experienced, that is not related directly, but is still graphic and performances related, is that a fullscreen game will be far more unstable fps wise than without being fullscreen, buuuuuuut I tested that on a computer with a 4 years old graphic driver, so I would think this is not useful in any way retrospectively. (Just to say, that without webGL, scaling the game seems to be more intensive, it was hardware accelerated as far as my browser said)

I've found this with games & other graphically intense items in general. I generally avoid fullscreen for this reason.

Ashley are you looking into this?

It's basically made my game completely unplayable below 60fps. Even in the high 50's the input delay and dt inconsistency are really noticeable.

Here's a log to verify that claim:

dt: 0.017 | FPS: 56
dt: 0.03299 | FPS: 56
dt: 0.00999 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.019 | FPS: 56
dt: 0.024 | FPS: 56
dt: 0.01399 | FPS: 56
dt: 0.01799 | FPS: 56
dt: 0.01799 | FPS: 56
dt: 0.03399 | FPS: 56
dt: 0.017 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.03299 | FPS: 56
dt: 0.01499 | FPS: 56
dt: 0.01799 | FPS: 56
dt: 0.01799 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.01499 | FPS: 56
dt: 0.018 | FPS: 56
dt: 0.03299 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.01599 | FPS: 56
dt: 0.018 | FPS: 56
dt: 0.01599 | FPS: 56
dt: 0.017 | FPS: 56
dt: 0.01699 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.01699 | FPS: 56
dt: 0.033 | FPS: 56
dt: 0.01099 | FPS: 56
dt: 0.01499 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.01699 | FPS: 56
dt: 0.02199 | FPS: 56
dt: 0.013 | FPS: 56
dt: 0.023 | FPS: 54
dt: 0.01799 | FPS: 54
dt: 0.019 | FPS: 54
dt: 0.032 | FPS: 54
dt: 0.01499 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.03399 | FPS: 54
dt: 0.024 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.016 | FPS: 54
dt: 0.017 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.016 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.016 | FPS: 54
dt: 0.017 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.016 | FPS: 54
dt: 0.02499 | FPS: 54
dt: 0.025 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.017 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.016 | FPS: 54
dt: 0.01799 | FPS: 54
dt: 0.01499 | FPS: 54
dt: 0.018 | FPS: 54
dt: 0.01599 | FPS: 54[/code:2xktw1s1]

I don't think it's a C2 bug, there's nothing much we could change on our end. It's a question of getting a minimal repro to pass over to browser vendors.

I tried a bit harder and came up with a new GPU-based repro, and I can get it to vary severely by drawing much larger rectangles on a mid-range laptop:

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

(If you've viewed it before press refresh to get the latest test - should draw ~1000x1000 rectangles and aim for 45 FPS)

I can get severe dt variations from 8ms to 44ms in Chrome. That's pretty extreme and the juddering is visible on the moving black box.

I guess we just need to figure out if this is widely reproducible (i.e. is it a good demo to show to browser vendors?) and then if so use it to file a bug report with affected browsers. So, does it reproduce it for everyone else?

BTW I tried that test in IE11 and the dt variation is sometimes much smaller (22-24ms) but it still looks pretty bad on the motion. Are actual games any better or worse in IE11? (I think a bug report with a title like "Chrome does X worse than IE11" should get their attention - it's worked before )

Throttling data, on desktop computer:

Chrome v38: 10-20 rects

Firefox v33: 40-50 rects

IE v11: 50-60 rects

BTW I tried that test in IE11 and the dt variation is sometimes much smaller (22-24ms) but it still looks pretty bad on the motion. Are actual games any better or worse in IE11? (I think a bug report with a title like "Chrome does X worse than IE11" should get their attention - it's worked before )

Subjectively, I've always noticed that IE seems 'smoother' than chrome/firefox, even if chrome/firefox is reporting lower cpu usage/higher frame rates. I haven't tested many other people's games in IE, but I've tested a number of my own projects.

It would be nice if there was some way to indicate to browsers that a page should be run in 'high performance mode', ie, long GC delays should be avoided if at all possible, display performance takes priority, and all logic should be compiled to the highest efficiency code possible, ASAP (preferably on another thread, like IE does).

blackhornet - you should report the min/max dt at 45 FPS, is that what your data is?

Chrome: 7 - 50ms

Firefox: 20 - 25ms

IE: 15-30ms

This is at around 50 rects on all browsers (60-70 for IE actually) I didn't check if any of the browsers are using the GPU (I'm on a dual GPU machine) but I don't think they are.

On my laptop, Intel HD4600,

Chrome v39 (beta), 22.1 to 25.5 ms

Firefox v33, 16.4 - 31.3 ms

IE 11 v 11, 20.8 - 26.2 ms