dt is not variable in chrome - cause of jank?

0 favourites
From the Asset Store
Color Variable
$4.50 USD
10% off
Easily store, modify, read and manipulate colors with Color Variables!
  • chrome doesn't have smoothly variable dt

    which makes jank really obvious in chrome

    if you make a simple program that plots dt against time (or add one into your game) , then stress the browser/cpu/gpu you will see that

    chrome does only 16ms OR 33ms

    nothing in between !

    i think this is a major cause of people's performance complaints and jank / stuttering complaints

    as soon as chrome cant handle 1/60, or something fires up outside the browser, even for a nanosecond, it drops a single 1/30

    then you get a nasty jank (even if you are framerate independent it is noticeable as your game only has one 33ms frame as reference for dt)

    the more stressed chrome gets the more single 1/30s it starts droping, the more janks you get.

    also if you are running on old or weak hardware , for chrome then it is a constant tug between only two choices , 16ms or 33ms

    and it will be dropping those sporadic 33s or 16s in singles

    so even if you are framerate independent the jankyness will be really obvious on older hardware

    but running in edge everything always feels much smoother

    even if ultimate performance might not be as good as chrome

    you dont get the big janks unless you really push it

    i was wondering why this was and when I run the same plot program in edge I see that dt is constantly and smoothly variable

    if something kicks in that might affect dt edge is smoothly manoeuvring dt ,

    edge will even try to compensate by following high dt with a few dt less than 16ms if possible

    and if you are pushing it , or on old or weak hardware edge will try to maintain a more regular, but higher, dt

    making your framerate independent game a much smoother experience

    im not a tech guy so I dont know how, when where dt is managed or calculated,

    i thought it would be directly managed by the cpu but it seems the browsers can treat dt in different ways

    Ashley

    is this a thing or am i talking sh1te?

  • Can you try this on edge?

    http://www.vsynctester.com/

    Chrome result: Occasional spike off the charts, some small spikes

    Firefox: Some small spikes

    Running these side by side: Chrome and Firefox do the small spikes in unison (interrupted by OS background processes?), but Chrome's off the charts spikes I cannot explain.

    As for the 16/32/64ms thing, it's from VSYNC. If anyone has a above 60hz monitor, they could try to see if there's more draw windows and thus less janky switch when missing a draw? People have reported that a higher hz monitor increases the fps cap to the monitor refresh rate.

  • I tested as well..

    In chrome i get some failures every now and then but overall smooth.

    In edge I got a bit more. everything from 1 to a few fails per second.

    In firefox it was pretty much constant fail. Broken.

    Tested on a surface pro 4.

  • http://www.vsynctester.com/chromeisbroken.html

    Holy crap. The bug still not fixed ?

  • Sorry I didn't mean to fire up the jank thing again.

    jank is a million times better than it was last year as far as I can see to the point that it is almost a non issue. ( Based on my limited number of admittedly mostly modern devices).

    Also on further research it seems maybe edge is not following proper protocol with its varying un vsynced dt. Where as chrome is.

    I was just wondering if there was a something about the chrome 30ms spikes correlation with construct game engine jank that might highlight some chrome or construct issue that would banish jank forever.

  • dt is measured with sub-millisecond accuracy. If it is locked on 16ms, it means the v-sync scheduling is so incredibly accurate, it's always exact. This means it's working perfectly! It's not a problem

  • Hi ASHLEY. My game is framerate independent and yes in chrome for the most part I am seeing 16ms with impressive performance from the construct engine. but those sporadic 30ms spikes always go hand in hand with a jank.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I made a test for others to see if they get the same results as I do.

    The skull spawns explosions each frame, you control the amount with +50 or -50.

    When dt goes over 25ms, it spawns "JANKY"

    CC exe: https://www.dropbox.com/s/4ckkxbez7iou0 ... C.zip?dl=0

    CC project: https://www.dropbox.com/s/ysfbukb3jnrpw ... l.cap?dl=0

    C2 NW.JS export: https://www.dropbox.com/s/uv9tw0guvq0vs ... w.zip?dl=0

    C2 project: https://www.dropbox.com/s/fos16fpcahcm4 ... .capx?dl=0

    Results for me:

    CC: at 600 /frame, no jank. Can stay jank free for minutes.

    C2: at 200 /frame, jank every second on Chrome and NW export.

    C2: at 50 /frame, Random jank every 5 seconds or so on Chrome and NW export.

    Can confirm on my GTX 1070 + i7 6700K:

    CC: at 950/frame, 28fps (running in background/not in focus), no jank

    C2: at 600/frame, 33fps (running in foreground/in focus), jank

  • You're only comparing the Chromium engine - have you tried Edge and Firefox? They have different v-sync engines. Edge was particularly good IIRC.

  • You're only comparing the Chromium engine - have you tried Edge and Firefox? They have different v-sync engines. Edge was particularly good IIRC.

    Chromium is the only option we have if we export to pc.

  • > You're only comparing the Chromium engine - have you tried Edge and Firefox? They have different v-sync engines. Edge was particularly good IIRC.

    >

    Chromium is the only option we have if we export to pc.

    Would a call for another wrapper fair any better than a native export?

    Make their own using Node?

  • The bottom left number is the dt when the test drops from 60fps, sorry that was a bit unclear. If that number is not updating, they're running at solid 60fps. Only when it says "JANKY" it's running sub 60fps.

    I've gone ahead and checked issues on Chromium that could possibly relate to jank from vsynctester.com - also starred some of them.

    There's also talk about the --disable-gpu-vsync flag that I haven't been able to get to work.

    On my desktop the CC version can show 3 times as many sprites without dropping frames than on IE, Chrome or Firefox.

  • Would a call for another wrapper fair any better than a native export?

    Make their own using Node?

    >

    > > You're only comparing the Chromium engine - have you tried Edge and Firefox? They have different v-sync engines. Edge was particularly good IIRC.

    > >

    > Chromium is the only option we have if we export to pc.

    >

    Would a call for another wrapper fair any better than a native export?

    Make their own using Node?

    Good idea, a dedicated wrapper would probably make a difference even if they never go into making a fully native engine. It might even mean they can make ports of Node exporting to consoles themselves.

    I think if they are willing to dig down deep enough into it, there are some performance gains to be had for sure.

    eg: Having something designed specifically for use by Construct might even mean they can do some native speed-hacks perhaps? (eg: intercept JavaScript math functions and return the result in some C++ code instead maybe? also for the built-in C2 plugins maybe they can offload that into some C++ code too?) even more useful would be if they had better control over the garbage collection/memory management, but I don't know if Node would enable that.

    Events for general game logic should be fast enough even if they are in JavaScript, but things that happen every single frame are going to be a source of jank, especially with the memory management/garbage collection being so bad in HTML5.

    Also, here's my results for testing in Firefox and Edge with 's project and C2 r246 running fullscreen on 1080p monitor with GTX 1070 and i7 6700k:

    Firefox: "JANKY" starts at 300/frame, gets awful at 400/frame, with dt reporting anywhere from 25 to 35

    Edge: "JANKY" both starts and gets bad at 600/frame, dt hitting 25 to 30. Gets as awful as Firefox at 700/frame

    I tried exporting CC to fullscreen and was able to reach 1300/frame before it started saying "JANKY" a lot, and even then it was still pretty smooth/didn't cover the whole screen in Janky

  • Sounds like a good idea,

    but I think Ashley will more likely dedicate time to the runtime engine rewrite once C3 out of beta, which will likely solve some of these issues anyway.

    On the same subject.... something that has been bothering me.

    why do we get janks even if our games are frame rate independent ???

    is it because the code can only ever use the previous dt in the current loop? so a single spike dt throws everything off. i.e. you need a more constant framerate for framerate independence to work smoothly ?

  • why do we get janks even if our games are frame rate independent ???

    is it because the code can only ever use the previous dt in the current loop? so a single spike dt throws everything off. i.e. you need a more constant framerate for framerate independence to work smoothly ?

    I think it mostly comes down to JavaScript being awful ( https://medium.com/javascript-non-grata/javascript-is-a-dysfunctional-programming-language-a1f4866e186f ), especially when it's not created via compiling C++ into JS with something like asm.js, but mostly also because it has poor memory management/"garbage collection" that will build up unused memory (eg: destroyed objects and variables) until it purges it and usually cause some lag. Many developers have been trying to improve this, as it's an issue larger than just Scirra: http://tinyurl.com/y8wfs8kx

    If I remember correctly, I think Scirra/Ashley actually has some great methods of reusing data to help combat the garbage collection.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)