About the jerkiness on the movement...

0 favourites
From the Asset Store
Run and Jump in 3 Dimensions! Take your platformer to the next level!
  • Another developer has identified and reported some v-sync issues in Chrome and Firefox. I've posted in their reports that this may be the issue behind the jank people have identified lately. Here's a list of bugs to follow if you want to track progress on this:

    https://bugzilla.mozilla.org/show_bug.cgi?id=1080869

    https://bugzilla.mozilla.org/show_bug.cgi?id=1028893

    https://code.google.com/p/chromium/issues/detail?id=424563

    https://code.google.com/p/chromium/issues/detail?id=422000

  • Thanks Ashley , I'm following the report now.

    I did a little test(just visual) with high contrast colors to Jank not be missed.

    The results are:

    Aero theme disabled

    Chrome 38:(wait a few seconds) a lot of Jank

    Canary 40 64 bit:(wait a few seconds) a lot of Jank

    It's funny that when Aero theme is enabled the result is very different:

    Chrome 38: Doesn't feel smooth, but I can't see the Jankiness

    Canary 40:Smooth and no Jank

    https://dl.dropboxusercontent.com/u/46383802/HTML5/bugs/jank/index.html

    Can anyone test this with Aero Disabled and Enabled?Maybe this just something related with my system specs.

    Thanks

  • Don't most people have Aero enabled these days? I think the latest Chrome Canary (v40) has the fix now, but I think it only works with Aero enabled. It measures a lot better on sbperftest here anyway in Canary.

    I just read that Firefox also has "Project Silk", which includes improving v-sync timing reliability, and should eventually make it to all platforms (they're targeting Firefox OS first). So it looks like both Chrome and Firefox are aware of the issue and have improvements in the pipeline.

  • Ashley Yes you are right, I do a lot of audio recording, and I have always the Aero Theme disabled to not waste resources, but usually people have Aero enabled.

    OK, if the Jank is fixed in 1 or 2 releases from now, I'll be more than happy, it's on Chrome and Firefox hands now.

    Thanks

  • Thanks for the investigation and the bug report to Chrome, much appreciated!

  • Another developer has identified and reported some v-sync issues in Chrome and Firefox. I've posted in their reports that this may be the issue behind the jank people have identified lately. Here's a list of bugs to follow if you want to track progress on this:

    https://bugzilla.mozilla.org/show_bug.cgi?id=1080869

    https://bugzilla.mozilla.org/show_bug.cgi?id=1028893

    https://code.google.com/p/chromium/issues/detail?id=424563

    https://code.google.com/p/chromium/issues/detail?id=422000

    Reading thru these bug reports is very interesting. This sounds like a lock for the regularly recurring jank reported by numerous C2 users. However, I don't think this bug covers all of the issues discussed in this thread.

    IE still handles high garbage, high CPU load, and FPS degradation far more gracefully than FF/Chrome. Firefox especially devolves into a glitchy mess with workloads that involve large amounts of garbage (dozens of objects being created/destroyed per tick). Now, generally, as designers, we should avoid such cases (In my case, I'm using a pre-optimized version of my current project. The newer versions recycle almost all the objects I'm creating/destroying in the tested build).

    The takeaway for me is this: even with a less efficient javascript engine, IE is providing much more stable performance than it's competitors.

  • I would probably not blame GC for any of the issues here. The engine is pretty good at recycling stuff. I mean it even recycles entire object instances. So even if you are constantly creating and destroying objects, it's actually internally recycling previously destroyed instances instead of allocating new ones. So you don't need to reproduce that in events. The rest of the engine has a similar approach of "recycle it all", so regardless of the content of your events, allocations and garbage creation should be minimal. Perhaps it is something else. Real demos with objective measurements are the best way to investigate it.

  • Ashley

    Obviously, you understand how the internals of C2 work better than us. But, maybe you could take a look at this example capx and see if you see a difference in performance between forced object recycling and normal create/destroy operations. Click to toggle between modes.

    https://www.dropbox.com/s/s2v4h18r172v4 ... .capx?dl=0

    P.S. GeometriX: I modded your capx for this.

  • TiAm, holy shiz! I wasn't a believer, but you've converted me. I definitely see the difference in Chrome (60 FPS event-based recyling, 20-50 FPS without it). And this is on my development PC which is quite a beast (at least per my standards). After reading the articles about garbage collection I figured it'd be a waste of time to recycle objects beyond what C2 already does behind the scenes, but this has me convinced otherwise. Looking forward to seeing where this discussion leads!

  • Ashley

    Obviously, you understand how the internals of C2 work better than us. But, maybe you could take a look at this example capx and see if you see a difference in performance between forced object recycling and normal create/destroy operations. Click to toggle between modes.

    https://www.dropbox.com/s/s2v4h18r172v4 ... .capx?dl=0

    P.S. GeometriX: I modded your capx for this.

    I would almost say it is an issue of the browsers trying too hard to find and delete objects on their own. It gets so concerned with locating/destroying objects and cant keep up with the game itself. (Non-recycled has 2000 objects vs 5000 recycled)

    Like I said earlier, the way the game works, only 1 thing really works at a time. So if the browser is focusing on figuring out what it should remove, vs us telling what to remove or even re-use it is going to slow things down.

    I also don't think that has much to do with the Jittery movement. Garbage collection might help performance for objects off screen, but rarely should be a real issue.

    If you need 2000+ objects all being animated off screen....you might be doing something wrong. Dynamic content creation would greatly limit how many objects you need.

    I am fairly certain the issue comes with refresh rates/v-sync as Ashley was saying.

    Locking movement at or below refresh rate removes all jittery movement.

    This is for both aero and non aero browsing.

    when I set my system to 144hz (144fps) the jittery movement can hardly be seen.

    60hz and 60 fps, again looks smooth.

    If I try to go above the refresh with movement, jittering is seen, more so at lower refresh than higher. Thats why I was making a big deal about the frames needing proper interpolation, tv's often do this. And in animation, getting smooth animations greatly comes from proper interpolation.

    I'm willing to bet, a project that has invisible sprites as the actual game and "real" positions with visible sprites interpolating to those invisible sprites will get that "smooth" effect people here want.

    I have to really really stress though, a square is much easier to see a jitter to movement than a fully animated player in an actual game environment.

    in "real world" uses, this "issue" is not so much an issue as people are making it out to be.

    Some1 feel free to yell at me if none of that makes any sense. I'm really tired today haha. And admittedly my brain is like bleghhh and spit forth thoughts. Enjoy <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz">

  • Is this a recent issue because over a month ago I did not have this issue (and never noticed it over my time using C2), but today booting up C2 r185 with the latest chrome, even a simple blank canvas with a few sprites moving around, there definitely is random jerkiness even though its reporting 60 fps.

  • - agreed. I never had this problem either until installing the latest chrome. I have noticed some improvement since installing the latest chrome beta. My old notebook had chrome 37 but before I got a chance to check it out, google auto update replaced it with 38 (even though I had auto update disabled).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • This just in: Small update in Chrome causes disturbances in C2 games and chaos amongst the Scirra Community. Will it be fixed? Who knows. "It's out of my hands. Stop blowing up my inbox" says Ashley, lead developer of C2.

    Thanks for watching and tune in next month for the exact same thing.

  • OK, well, if you're creating/destroying 100 objects per tick then the CPU overhead of the create/destroy actions comes in to play. These need to do things like update object instance lists, families, containers, initialise the default state, initialise behaviors and so on. Most people don't create hundreds of objects per tick so it's not a significant overhead, but in this case it is measurable. I still don't think it's anything to do with garbage collection. The engine still recycles objects when it creates them, but creating an object just involves more work than re-positioning it. So in this specific kind of use case (you're basically recreating particle effects with sprites) repositioning is cheaper, but this does not prove garbage collection has any involvement at all.

  • Will it be fixed? Who knows. "It's out of my hands. Stop blowing up my inbox" says Ashley, lead developer of C2.

    Uhh, how about "it's already fixed in Chrome Canary and Mozilla are working on it too"?

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