Ashley's Forum Posts

  • What measurements have you made that identify this event as the cause?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Crosswalk is just a custom build of Chromium, so I don't think there's any point reporting it to them as well, just wait for it to get fixed in Chromium.

    A monitor running at 59 Hz will probably not help! A lot of games and possibly browsers are tuned to work at 60 Hz since it's the most common refresh rate, and being slightly off that could make you drop frames...

  • I don't think it's a C2 bug, there's nothing much we could change on our end. It's a question of getting a minimal repro to pass over to browser vendors.

    I tried a bit harder and came up with a new GPU-based repro, and I can get it to vary severely by drawing much larger rectangles on a mid-range laptop:

    http://www.scirra.com/labs/bugs/fpstest-gputhrottle.html

    (If you've viewed it before press refresh to get the latest test - should draw ~1000x1000 rectangles and aim for 45 FPS)

    I can get severe dt variations from 8ms to 44ms in Chrome. That's pretty extreme and the juddering is visible on the moving black box.

    I guess we just need to figure out if this is widely reproducible (i.e. is it a good demo to show to browser vendors?) and then if so use it to file a bug report with affected browsers. So, does it reproduce it for everyone else?

    BTW I tried that test in IE11 and the dt variation is sometimes much smaller (22-24ms) but it still looks pretty bad on the motion. Are actual games any better or worse in IE11? (I think a bug report with a title like "Chrome does X worse than IE11" should get their attention - it's worked before )

  • Those are ancient performance tests, we've made loads of engine optimisations since then. Try this one:

    https://www.scirra.com/demos/c2/renderperfgl/

  • Well you bumped a thread where I made comments about three years ago, and my stance has changed: as long as you have a decent SSL implementation, you should be OK - but you should still send password hashes and not actual passwords, so they're not even plaintext on the receiving endpoint. Anyways I don't consider myself a security expert so don't ask me.

  • Check your graphics drivers are up to date.

  • Yeah, HTML5 has always been "at the mercy of" each browser maker, but they're generally actually doing an amazing job and improving things really fast. This is just the latest quirk really - wind back 3-4 years and all you had were software-rendered canvas2d with crappy audio support, so things are always getting better. Remember Chrome and Firefox are both on rapid release schedules so if/when this is sorted out, the fix will be out to everyone in short order. And IE with its slower release/update rate doesn't appear to be affected (at least here), so that's less of a worry (if IE was affected then it would definitely be a long outlook to get it fixed).

    BTW perfect Vsync is actually pretty hard to achieve - I remember some similar complaints with Construct Classic, which was native C++/DirectX 9 (and note did not have any garbage collection). They were just very small occasional skipped frames. I think ultimately with an OS which is task switching on maybe a 10-20ms frequency, having to very precisely render at 16.7ms intervals to vsync properly, is a high bar to reach, and realistically the odd frame is going to get skipped.

  • Heh, filing a bug saying IE11 does better seems to have done the trick - they've already assigned the bug

  • I've looked in to this in the past and I think it's JIT compilation in the Javascript engine. It seems to vary depending on the browser and system. As usual you should test on every browser available to identify issues which are browser-specific. In this case while generally very smooth, sometimes it's a bit janky in Chrome and Firefox. But surprisingly IE11 is rock solid and I basically never see any issues there.

    I'd point out this isn't "HTML5's fault", because HTML5 is simply a specification, and it's not like the specification says "browsers must pause for a frame every N frames". It looks like a quirk that Chrome and Firefox are subject to at the moment and I don't think there's any reason it can't be fixed. There's no reason something like this has to be inherent to browser games.

    Some random thoughts that I think support the JIT compilation theory:

    • we've done loads of work to reduce the garbage created by our engine (specifically to avoid jank like this ), and it's generally very good at recycling stuff and not needing any significant GC work at runtime. Also modern browser GCs are very good at doing work in lots of little slices instead of having to pause everything while it does work. So GC should not be a significant issue.
    • Construct 2's engine is pretty big in terms of lines of code, since it has loads of features and does a lot under the hood. JIT compilers compile on-demand for faster startup. They have various thresholds for compilation like "if a function has been called 100 times, compile it". This means they don't have to compile everything, which likely includes lots of code only ever called once. However it does mean random bits of code end up getting compiled mid-gameplay at non-deterministic times. The size of C2's engine would explain why other smaller engines might not be so affected.
    • IE11 apparently has a completely parallel JIT compiler, which would explain why it is so smooth: it's compiling functions in the background while the game continues to run, and just quickly swaps in the finished code when it's done. On the other hand I saw a Google engineer mention that V8 sometimes has to compile synchronously (i.e. causing jank, since it has to stop and wait for it).
    • WebGL mode moves more of the rendering logic in to JS code. It usually way outperforms the canvas2d renderer, but since more rendering code is in the JS engine, I guess it could be more subject to jank from compiling that code.
    • after a while (15-30 seconds?) the JIT compiler should have basically compiled everything. This explains why it might be janky for a bit at the start, and then get smoother. If you are only seeing problems on startup, try allowing the game to run for a while to "warm up" (so everything which is called a lot is already JIT compiled), and then it should be smoother.

    However this is solvable: if Chrome and Firefox are as good at parallelising JIT as IE11 is then it should be fine everywhere. Also simply waiting out the warmup period should make it a lot better. Hopefully most games are just showing a menu or intro credits type sequence at that point. I've also heard the V8 team are working on a new compiler called "TurboFan", which I can't find much information about, but parallel compilation would be an obvious improvement to make for a new compiler.

    I had already filed bugs with Chrome and Firefox based on sbperftest since it actually measures jank and dropped frames providing an objective way to measure the problem and provide a yardstick to compare improvements. The bugs I filed don't seem to have gotten much attention yet. So comments and stars on these reports could help them get attention:

    Chrome issue 387675

    Chrome issue 424563 (which I just filed now to point out IE11 does better than Chrome)

    Firefox bug 1028893

  • Do you need it right now?

  • socialpilgrim - you bumped an old thread with out of date information - the signalling server is now available.

  • Did you try other browsers? Are you using Chrome, Firefox, IE or something else? Which browsers show which error messages?

  • I want to ultimately replace the box2d physics engine with the asm.js version, but it needs rewriting and recompiling with Emscripten which is a bit tricky. Until then I don't want to make that port even harder by adding more features unless both the box2dweb and asm.js runtimes can handle them, and it can be a lot harder to get new features working in asm.js.

  • At this moment, I updated GFX driver and I tried to test Space Blaster again with Firefox 33, it runs smoother, weird!

    Yep, sounds like you had an old driver which Firefox blacklisted.

    I think you can view your hardware acceleration status by going to 'Troubleshooting information' and checking the "GPU Accelerated Windows" property. It seems a bit obscure, but apparently it says 1/1 if it's GPU accelerated, and 0/1 if not.

  • Firefox 33 works great as ever here for me. Maybe your card got blacklisted in this release?

    The "render name unavailable" is really irrelevant, it literally only means the browser doesn't want to give out the graphics card name for privacy reasons.