dt is not variable in chrome - cause of jank?

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.

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?

Tried that in Chrome (61.0.3163.100 official build 64-bit) on my i7 6700k, GTX 1070, 16GB DDR4 RAM:

~35 dropped frames

1sec jank: 0.1ms

Avg jank: 1.8ms

Max jank: 16.7ms

Est. CPU: 6%

Max CPU: 4%

Status: done

Test score = 59

rev14

Would love to see a test like that running 1 or 2 instances of the platform behavior.

Edit: Noticed my Chrome was out of date, tried it again after update (62.0.3202.89 Official Build 64-bit)

~13 dropped frames

1sec jank: 0.1ms

Avg jank: 0.6ms

Max jank: 16.7ms

Est. CPU 8%;

Max CPU: 4%

Status: done

Test score = 60

rev14