Scrolling Stutter/Jank Theory, Seems Session Dependent???

  • Consider the following scenario:

    1) Open a preview of your project and begin scrolling, no jank/stutter experienced at all

    2) Close the preview, open a new preview, begin scrolling: consistent jank/stutter

    3) Repeatedly open and close preview sessions testing scrolling and discover that it's a toss up between having and not having jank/stutter.

    CPU in each case: approx. 30%

    FPS in each case: 57-58 (Never goes higher regardless of the project, could this be a causal factor? (If so, then why would it be smooth in certain sessions with the same FPS vs not smooth in different sessions with the same FPS?)

    -I'm far from an expert, but if this issue was event based, considering that each session is independent, wouldn't the jank/stutter be experienced everytime?

    -If it isn't event based, what theories do you have on why this stutter/jank when scrolling would be session dependent?

    - I've seen many instances of the jank/stutter pop up throughout the community and I've not been able to pin down a fundamental cause of this issue.

    -It's basically come to the point where if I can't resolve the jank/stutter issue I will have to move on to another means of development.

    In anticipation of Ashley or anyone on the Scirra team asking for a cap. I'm willing to send it privately.

  • It's loading a browser right so maybe it's an issue with that. The true test would be to play the exported game and see if you have any performance issues.

  • It's loading a browser right so maybe it's an issue with that. The true test would be to play the exported game and see if you have any performance issues.

    I tested the following scenarios for about 20 seconds of scrolling upon layout initiation:

    Exported Windows 64-bit NW export: Jank Free Sessions 20/20 (0% Jank Session Occurrence)

    Preview In Project: Jank Free Sessions: 14/20 (30% Jank Session Occurrence)

    I will probably extend this out to at least a 100 sample size.

    In the case of the in-browser preview, I'm not versed enough to understand the underlying processes at play, however, I find it interesting that it is in a sense a boolean type of outcome. If the session starts with the jank/stutter it remains, regardless of if I wait 5 seconds or 1 minute before testing the scrolling.

    From my point of view, I can understand some initial stuttering at the beginning of a layout, but the persistence makes it appear as though something becomes out-of-sync upon initialization and remains out-of-sync.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • True something could be off with the preview, it's within Construct and only a preview of the game. I wouldn't be too bothered about investigating issues with the debugger and preview tools, seeing that the performance is 100% fine on an exported version then I know my game is good when not using test tools, but that's just me.

  • Yeah, I was actually surprised by the export scenarios performance. I recall experiencing the stutter/jank on a previous NW export so I was not overly optimistic. If the export does not have the issue, I can "deal with it" for now.

    It's still quite puzzling how essentially at the beginning of the session it is decided whether or not there will be stutter/jank for the remainder of the play session.

    I'd feel way more comfortable with development if we could nail down this issue (assuming it's a fundamental one, as there are a lot of variables to consider)

  • People have been bringing up jank from time to time over the past few years. Ultimately for flawless jank, a frame needs to be rendered every ~16.6ms without fail. Rendering a frame means running all the logic for a frame, issuing draw calls, which then go through a highly complex graphics driver and compositing stack, all the way to the physical display. This is a long and complicated process that all computer graphics go through, and the regular 16.6ms deadline is a demanding one. All it takes is something happening in the background, such as a backup, virus-scan, or other resource-intensive activity like launching an app or performing background work in the OS, which steals a few milliseconds of work and the frame deadline is missed, causing jank. Fullscreen games usually bump their priority up and pause background work to ensure rendering is smooth, but windowed content has to contend with everything else happening on the system. So I think jank is likely to always be possible in a windowed game, and the behavior tends to be non-deterministic since it depends on system-wide activity working towards millisecond deadlines.

  • Hey Ashley, thanks for the response. In a non-deterministic case, in which a multitude of activities can lead to what we perceive as jank in any given session, what do you think would result in the session-long jank, rather than a transient situation? Presumably, the activities that resulted in the jank would eventually be resolved, yet in my experience, if I see jank in the first few seconds I will continue to experience this jank until the session ends. Is there some technical aspect that would essentially label the session as ("jank"), and would no longer update this label/state once the background or even foreground processes are resolved?

  • If you're running Windows ctl-alt-del and bring up task manager. Select the performance tab. Keep a watch on the charts as your app runs. If you're seeing some wild spikes in say disk activity or cpu usage, then it's likely a background process causing the stutter or even the browser itself.

  • I always butt in at this point, like a broken record to say....

    With C3, previewing in the browser is usually gonna give some jank, and is not indicative of web hosted or exported performance. Just use it as a rough guide.

    Upload it to a server or export it to nwjs and, on the same machine you should see little to no meaningful jank and noticeably higher and smoother performance.

    edit and if you are on a laptop or tablet make sure you are not running on battery saver (or equivalent). in fact plug in and max the performance settings if you can.

  • Actually I think it's also worth mentioning the "use worker" mode is pretty new and may have different jank characteristics. So it might be worth trying with that both on and off.

  • With C3, previewing in the browser is usually gonna give some jank, and is not indicative of web hosted or exported performance. Just use it as a rough guide.

    It's not so much that there is "some" jank it's more so the binary nature of its occurrence. One session: smooth, the very next janky, then the very next smooth, with no discernible change in the environment in which I am previewing the game. So in other words, if the browser is capable of previewing the project smooth without jank, it would be great to pinpoint what exactly is resulting in this binary occurence. Again, if the export to NWJS is fine, then I'm not really that worried. However, I did export this as an HTML5 and uploaded to itch.io and did experience the jank, so does it stand that Construct 3 (An HTML5 based engine) will be prone to this potential jank/stutter problem regardless of the optimization set forth in the development of the game if the browser is involved? I honestly have no idea, again there are a lot of variables to consider.

    If you're running Windows ctl-alt-del and bring up task manager. Select the performance tab. Keep a watch on the charts as your app runs. If you're seeing some wild spikes in say disk activity or cpu usage, then it's likely a background process causing the stutter or even the browser itself.

    I ran with task manager 20% CPU, however unlike in debugger mode where it displays about 12% GPU it shows 60%, is this difference worth mentioning? In both cases with and without jank the performance graphs looked similar, no significant spiked associated with the janks/stutters.

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