Request Animation Frame Causing massive jank?

Reading a bit about garbage collection to understand it better... From what I've read some ways to reduce jank was to do it on other threads, or schedule GC in idle time.

Is there something that can be done on your end or is this purely browser related?

For me it's not that big of an issue, but I would prefer silky smooth if possible.

I did a simple test scene that just spawns randomly spawns a few sprites that move across the screen. No behaviours, no text objects, or anything.

Still getting janks every now and then. I guess there's nothing more I can do at this point...

It's not a game breaker but a bit annoying and quite noticeable at times.

[quote:z8ir066t]It looks like the jank comes from a "Create object" action. My best guess is that you are creating an object that is not already placed on the layout, so does not have textures pre-loaded when the layout starts. This means when you create it, the engine is forced to load its WebGL textures on-demand the moment it is created, which is very expensive and can definitely cause jank. This is why you should take advantage of layout-by-layout texture loading, which uses the fact an object is initially placed on a layout as a signal to pre-load it. (You can destroy it on start of layout if it doesn't need to be there initially, but must be placed on the layout for Construct to pre-load it.)

Now this is useful information.

Here's a link to the test scene. Just moves sprites across the scene.

https://www.dropbox.com/s/gd1tk3p9c75op ... t.c3p?dl=1

Just leave it running and occasional janks will appear randomly every now and then. I always thought it was something with my events and something I could optimize later on when game was getting closer to finished state.

Ashley is this something that might improve with the new runtime as well? Or are we at the mercy of browser engines here?

It looks perfectly smooth to me. I've seen a lot of these kinds of tests over the years, generally aimed at v-sync quality - they tend to look fine for me these days. For example on my system the space blaster vsync test can hit every frame within 0.1ms over a period of a minute. There does seem to be variation across systems as to how liable it is to jank.

FWIW GC is entirely on the browser's end, but in modern browsers it's all designed to run in tiny slices of just a few milliseconds to avoid jank. It shouldn't be holding up for a noticable amount of time.

It could actually be a browser addon spewing out rubbish in to the GC - have you tried disabling them?

It looks like the jank comes from a "Create object" action. My best guess is that you are creating an object that is not already placed on the layout, so does not have textures pre-loaded when the layout starts. This means when you create it, the engine is forced to load its WebGL textures on-demand the moment it is created, which is very expensive and can definitely cause jank. This is why you should take advantage of layout-by-layout texture loading, which uses the fact an object is initially placed on a layout as a signal to pre-load it. (You can destroy it on start of layout if it doesn't need to be there initially, but must be placed on the layout for Construct to pre-load it.)

I do not know if I am going off topic here, but is this advice a general advice to follow on medium to big projects?

Right now I put almost all images in 1 layout.

Yes. See the section on layout-by-layout loading in the manual.