dt is not variable in chrome - cause of jank?

  • 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.

  • Because there is no such thing as frame rate independence. DT is like taking a pill for your headache, alleviates the symptom, but doesn't cure the actual problem.

  • Edge was particularly good IIRC.

    After keeping an eye out for frame drops, it seems like EDGE is clearly superior to Chrome in hitting VSYNC consistently. In fact I never notice a stutter or a missed VSYNC when testing my game on EDGE. It refuses to miss a beat unless you deliberately stress it, but then it will drop frames consistently too.

    The bug reports on chromium also seem to indicate that when Chrome misses the beat, it's not gonna be 1 frame but possibly more. From what I understood, it could still have a 2 or 3 frame gap between a correct VSYNC and a missed beat after which Chrome gathers itself and composes the image. It would go like frame 1 on sync, frame 2 misses vsync, gets DT of 33, but is composed a total of 2 frames later compared to frame 1, so this makes the jankyness even more pronounced when the correctly DT adjusted frame is displayed with additional delay, then the next frame hits sync and is shown "early" compared to frame 2.

    By association all NW.js projects suffer from this, so it's important to find a way to push improvement to chrome or possibly find a way to hax NW with a temp fix until it's sorted.

    -edit

    these are the issues on chromium. Latest comment does indicate there's work being done, but the more stars these have the better:

    https://bugs.chromium.org/p/chromium/issues/detail?id=422000

    https://bugs.chromium.org/p/chromium/issues/detail?id=460919

  • huZba I have noticed this too but, never took any notice before until Ashley mention this Edge was particularly good IIRC

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

    Make their own using Node?

    Just thought I would point out something.

    Multimedia Fusion also suffers from this janking as seen in this thread: https://community.clickteam.com/threads ... tus-thread)

    So, I guess this is an example of a native option not being a solution.

  • >

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

    > Make their own using Node?

    >

    Just thought I would point out something.

    Multimedia Fusion also suffers from this janking as seen in this thread: https://community.clickteam.com/threads ... tus-thread)

    So, I guess this is an example of a native option not being a solution.

    Native is one solution, but like with all things, it's possible to make mistakes so Fusion 2.5 is unable to hit monitor vsync accurately at all times. In this case the engine vendor can fix the problem themselves. I hope Fusion 3 will have fixed this completely.

    In case of Construct 2, the problem is that the ball is on Chrome. The issues are known and at least there's a promise that "there's work being done on it". I'm hoping for the best but not holding my breath.

  • hmm, that's a fair point, I forgot about that.

  • Notice also in that thread that Chowdren exporter boosts performance? (It also allows console export)

    There are no options like that for us unless Construct supported an abstracted export that lets people make their own runtimes and importers (like Spriter does)

    Making a whole HTML5 wrapper doesn't remove the slowdown of JavaScript and the incompatibility of WebGL on older hardware and consoles

  • This is what I've been saying all along - making our own native engines won't necessarily solve any of the problems people think it will.

  • Maybe someone will do a reverse Emscripten some day.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Actually if Construct exported to Emscripten/ASM.js we probably wouldn't have a lot of the issues we do. I remember the Unreal Engine 3 Firefox WebGL test from years ago and it ran smooth on my older PC. Construct Classic still runs smoother than C2 on my new PC running:

    i7 6700k

    GTX 1070

    16 GB DDR4 RAM

  • Godot uses it for html5 builds, but it ends up adding 50 megs.

    On the other hand CC would have been about half the size of C2 html5 exports.

    Then again I've got hundreds of megs from Dx9 runtime updates from back then.

  • This is what I've been saying all along - making our own native engines won't necessarily solve any of the problems people think it will.

    To move the issue at hand toward a solution, ideas on how the chrome issue could be resolved are welcome.

    I've starred these:

    https://bugs.chromium.org/p/chromium/is ... ?id=422000

    https://bugs.chromium.org/p/chromium/is ... ?id=460919

    ,but wonder if there's something else that can be done.

    Is hiring a coder to fix this on a custom one off NW.js build for my game a feasible backup plan?

    EDGE runs rock solid dt 1/60 for extended periods and feels so much better than an NW.js export.

  • As ever, you can make a minimal repro of a problem and file a bug with Google directly. I just checked again and in Chrome, for me, sbperftest's jank meter is locked on 0ms, indicating perfect v-sync. I presume there is something device-specific about any jank issues, and v-sync is implemented in the Chrome browser anyway, so it makes more sense to cut us out of the process and take it up with them.

  • As ever, you can make a minimal repro of a problem and file a bug with Google directly. I just checked again and in Chrome, for me, sbperftest's jank meter is locked on 0ms, indicating perfect v-sync. I presume there is something device-specific about any jank issues, and v-sync is implemented in the Chrome browser anyway, so it makes more sense to cut us out of the process and take it up with them.

    I'd like to see some screenshots of people going through a round to see what the max jank is for each user, then also post their monitor refresh rate, OS and specs.

    Would you happen to have a 144hz monitor Ashley ?

    --edit : The refresh rate might not be relevant.

    Tried the test with a laptop and it ran once through with showing 0 on the jank, then updated chrome from 61 to 62 and it started showing random 16ms janks here and there. The change after update might be a coincidence tho.

    --edit:

    Desktop i5 GTX960, 60hz, Win10, Chrome 62 - Random jank throughout the test

    Laptop Zenbook i5 GTX940, 60hz, Win10, Chrome 61 - No jank on the test, Chrome 62 - Random jank.

    Laptop MacBook Air i5 Integraged HD 5000, Chrome 60 - No jank on the test

    Will try to cross reference each of these, but start by trying NW.js with chrome versions 60 and 61.

    Is there a capx for the sbperftest?

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