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.

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?

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)

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.

So after further testing, the minify script option only updates whether or not it can be enabled after you close and reload the project. Thus, even after deleting everything in the project, the option was only available after reloading. (In my specific case at least)

Update: found the javascript, by isolating the event sheet that once deleted allowed for enabled minify script. Then searched through that event sheet.

P.S. is there any means by which to locate a blank javascript within the event sheet?

It tells you in the export dialog why:

> NOTE: this is not yet supported for projects that use JavaScript code.

It's on the todo list to add support for that.

Perhaps I am misunderstanding but are you saying that even on a blank project (Having deleted everything except the mandatory single layout) minify script being grayed out is normal?

I can't minify my export without it ((I think I might have accidentally added an empty javascript code within my event sheet, (minify script is greyed out))

Update: Decided to systematically delete every part of the project to determine what's causing the minify option greying out. I ended up deleting the entire project and removing any addons that aren't the default and still can't minify script.

P.S. using the latest stable build

Any ideas?

I'm attempting to keep my event groups organized, but this often results in situations where I'm setting conditions such as "Every 1 Second" in multiple areas in multiple event sheets to maintain organization in terms of keeping that condition in the designated group. Ideally I would want a single Every 1 second parent condition and all sub events pertaining to that condition underneath, right? If that's the case how much of a performance hit does a situation like this result in.For example: Assume you have 10 separate events with the exact same parent condition "Every 1 Second" And then a varying amount of actions that, for the sake of this example, all result in the same amount of CPU usage. How much of an impact would it be for those 10 events to be separated vs. having one event with a single "Every 1 Second" parent condition followed by the 10 sub events within that parent condition?

VS

Apologies if this has already been addressed somewhere else.

Best,

OneRepCloser