We need to talk about the Jank!

Looking at the devtools memory profiler, C3 games looks like the above graph.

Below: Static memory allocation for javascript. I don't know if static memory for C3 games might solve it, or even possible but the jank needs to go.

FWIW, I just checked endless runner in Firefox, and it's just as bad. :(

> Looking at the devtools memory profiler, C3 games looks like the above graph.

>

>

>

> Below: Static memory allocation for javascript. I don't know if static memory for C3 games might solve it, or even possible but the jank needs to go.

>

>

FWIW, I just checked endless runner in Firefox, and it's just as bad. :(

Yes, platform, browser, mobile, desktop doesn't matter. The janks are haunting me... :p

Here we go again... No, honestly the Original Poster (OP) has a good point... But still, here we go again.

Anyway, yeah it's even worse on mobile. I personally experience the janks, but at the end of the day, it comes to.

1. Can you prove it?
2. Do you have time and resources to make a case?

I'm thankful someone addressed this though. Because we really need proof and a test case right now.

It's easy to prove. Just run devtools and record performance and check the for the hickups. Most times it's major GC causing it.

> Here we go again... No, honestly the Original Poster (OP) has a good point... But still, here we go again.

>

> Anyway, yeah it's even worse on mobile. I personally experience the janks, but at the end of the day, it comes to.

>

>
1. Can you prove it?
>
2. Do you have time and resources to make a case?
>

>

> I'm thankful someone addressed this though. Because we really need proof and a test case right now.

It's easy to prove. Just run devtools and record performance and check the for the hickups. Most times it's major GC causing it.

Whatever the cause I'm only interested in real world scenarios (finished Games), not the whys and whatnot's and technicality's, and in a real world scenario, the endless runner isn't good publicity for a flagship piece of software, if anything it would put people of purchasing it.

I've put several projects on hold because of this, nowadays mostly using C3 for playing around with and prototyping, until a solution for the janks was in place.

My first hope was the C3 runtime would fix it. - It didn't

Second hope was that the Worker would fix it. - It didn't.

I love Construct but I'm reluctant to finishing and spending more time on any real C3 projects if I can't even control or minimize the janks.

What's the point of finishing publishing your games if you know that there will be a shitstorm of complaints and bad reviews because the users experience performance hiccups and janks.

I've done all I can in terms of optimization. Besides from janks runs at constant 60fps even on mid range phones.

This really needs to be adressed. :( I would love to finish them up in C3. but the janks are putting me off from spending any more time on it.

I can't reproduce any issue on my system with Chrome 69 - it's perfectly smooth even in fullscreen, and there is no GC coming up in the profile at all. In the past jank issues have been more to do with the OS, graphics driver, or browser v-sync schedulers or compositors anyway. You could prove GC by using the performance timeline in Chrome and looking for what it's doing in the time periods when it janks - the sawtooth shape graph is normal for a garbage-collected language and doesn't itself prove anything.

Citing articles from 2013 will be missing the past five year's worth of GC improvements in browsers: most of them are now generational, incremental and concurrent - specifically designed to avoid more than a few milliseconds of pause at any one time, specifically to guarantee a smooth uninterrupted 60FPS framerate. If they can't do that, it's probably a bug with the browser's GC.

Either way - v-sync scheduling or GC - it's not something we directly control, so your best bet is to collect evidence identifying the GC (if it is), and file a clear bug report at crbug.com. There seems to be a tendency to post long, complaining forum threads on our forum when there's nothing much we can do about it - if you're actually serious about sorting it out, reporting issues to browser vendors is the way to go. In the past they've fixed similar issues quite promptly (e.g. this issue which they first submitted a patch for within 2 days).

With all due respect, It's nothing I'm imagining, and definately something I'm noticing everywhere and is recording when using devtools.

Chrome, on desktop and on mobile. Windows and Android, IOS, MacOS,

Firefox on desktop and mobile. (although firefox on mac less often) Windows and Android, IOS, MacOS

I'm pretty sure GC works as it should on regular webpages, but For HTML5 games i've seen articles suggesting to use Static memory allocation and other techniques to reduce GC janks. Minor GC doesn't seem to cause any janks, but for some projects and in some cases i get quite a lot of Major GC janks. But for games i'm guessing you would want to eliminate janks and GC altogether.

Just took this on chrome 69 on a powerful macbook pro. Those major GC janks often come in regular intervals. Sometimes more frequent, sometimes less. No browser extensions, no tabs other than Construct.

I just don't know what to make of it...

Found this reported bug, which might be related?

bugs.chromium.org/p/chromium/issues/detail

This happens across browsers though, more or less.

Hey tunepunk looking at the GC you show in your screenshot it takes roughly a third of a normal frame(5.5ms) to complete, and as far as I can see in your profiler image there's nothing else occurring for the remaining 40ms of that frame. I expect it's managing to line up with some other large task the browser was doing that isn't shown on the flamegraph. Also worth remembering that when using preview chrome will share the process between your game and construct, so performance isn't completely representative.

As ash said GC has changed a fair bit in the last few years. Chrome prefers lots of small GC calls during expected idle time to avoid long blocking GC pauses. The side effect of that is that your memory graph will often appear as a sawtooth, even when there isn't a memory pressure. It's also worth noting that despite chrome labelling that as a "major GC" it was only 400KB ( max heap 34MB ), the graph you referenced is showing GC of about 80MB ( max heap 190MB ) so not only is construct using a lot less memory but the GC was 20 times smaller!

In terms of static allocation, it doesn't magically improve performance. We use it where possible but often it's just not feasible to use. In my experience, forcing the use of static allocation everywhere you can makes code a lot harder to work with, increase overall memory pressure and in some cases can have a negative performance impact.

I'm not trying to wash over the issues your having. Dropped frames definitely suck, and I have to say I've been having a slightly rough day in regards to chrome 69 bugs. I have spent most of the day working in canary instead, so I'm hoping to see some form of maintenance release over the next few days.

Perhaps could you upload the profile you took for us to look at? You can save it as a JSON from the timeline. It might answer more questions than a screenshot.