We need to talk about the Jank!

0 favourites
From the Asset Store
High quality footstep sounds that're perfect, for adding realism to any project needing lifelike footstep audio.
  • Ok, so I just upgraded to latest chrome stable. 69. My main problem with C2 has always been the jank, which mostly seems to be caused by GC (garbage collection)

    Usually I use the endless runner template as a benchmark, since the jank becomes very apparent in sidescrollers that should have a steady x movement.

    I always noticed some jank but latest C3 (r115) and latest chrome (69) the jank is just ridiculous.

    Starting a small simple game like endless runner produces so much jank it's not even fun to play.

    And I'm playing on a good spec, MacBook pro.

    MacBook Pro (15-inch, 2017)

    2.9 GHz Intel Core i7

    16 GB 2133 MHz LPDDR3

    Radeon Pro 560 4096 MB

    Intel HD Graphics 630 1536 MB

    What is going on here?

    Once in a while it runs smooth for a while, every other preview it seems like it's going in 15fps. Other runs i get major GC janks ever 8-10 seconds or so, and sometimes i get massive janks even without GC.

    I really wanna get to the bottom if this, because it's ruining the whole experience. Spending hours and days weeks to optimize your game to be lightweight and smooth, but getting janks that are out of your control, that shouldn't be there...

    Ashley

    Can we please delve deep into this and find out what's causing it and how to combat it?

    Running worker doesn't seem to help either, and my tests with worker only make it jank even worse.

    I'm pretty sure it's not my system, because I'm experiencing this on a variety of platforms and specs, OS, mobile, desktop, browsers whatnot.

    New edit & update

    Due to recent findings I'm updating here.

    This seems to happen mostly on laptop or windows devices that are on battery or running a balanced/power plan. Can possibly be caused by other things but this seems to be a major factor. It's explained here.

    vsynctester.com/manual.html

    Thanks for the find Asmodean !

    Specifically in segment 3 & 4

    There doesn't seem to be much one can do though, as this is out of anyones control, Scirra, Browser vendors. Only possible those responsible for power management could fix this.

    One idea to mitigate it somewhat is to tax the CPU so that it doesn't wind down clock speed on low cpu usage. I'm going to try it out and see if works, and update again and report my findings.

  • I don't know if it's any help.

    But point 6 here, might have some tips and links on how to reduce the GC janks.

    calendar.perfplanet.com/2013/the-runtime-performance-checklist

    html5rocks.com/en/tutorials/speed/static-mem-pools

    They become very apparent when they do happen. especially in games with a lot of movement/scrolling

  • I can confirm this, as I am toying with an endless sidescroller, and the jank is horrible with 115, in c2 and c3 runtime, with or without worker, any scrolling background janks like crazy, it was not brilliant before, but this is horrible.

    I'm probably going to ditch this project, if there are no improvements.

    If anyone needs to see it, just download endless runner template, and set the platform plugin to disabled, sit back and watch.

    BTW, I'm a great advocate for the construct software, but sometimes things just have to be said.

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

    However for high-performance web applications, like HTML5 games, the GC can often eat away at critically needed frame rate, reducing the experience for the end user. With some careful instrumentation and adoption of object pools, you can reduce this burden on your frame rate, and reclaim that time for more awesome things.

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

  • 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. >
    3. Do you have time and resources to make a case?
    4. >

    >

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Found this reported bug, which might be related?

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

    This happens across browsers though, more or less.

  • I can reproduce this in Chrome 69 as well (high-end Desktop PC). Judging based on my performance profile, GC is all out again and doing its thing whenever it likes to, this time it seems to trigger whenever Construct performs runtime work with draw calls in it.

    Speculation Alert: This might be caused by objects being destroyed or created.

    I'd do a Chromium bug report but this example is a bit too unreliable for me. Currently trying to figure an example which triggers GC calls by doing the things mentioned above.

    If anyone's got suggestions or a more reliable example, please post it here and I'll check it out.

    Found this reported bug, which might be related?

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

    This happens across browsers though, more or less.

    Nah that's something else, nothing to do with this issue.

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

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