Violation ‘requestAnimationFrame’ handler took ms when pre-loading multiple textures. Causes hitches and drops in framerate

Hi all, here is an issue that is confusing me. I am getting a
“Violation] ‘requestAnimationFrame’ handler took ms”
as well as a ‘pointerdown’ handler took 250ms

With a noticeable hitch and drop in framerate.

Obviously something is interfering with requestAnimationFrame and I bet I am doing something bad with async await and promices.

Ive boiled it down to what i think is causing it…code that I have set up to pre-load an array of textures. simple stuff that uses BaseTexture.WhenAllReady.

If I do not pre-load textures (eg: just return new Texture(url,scene) without waiting for the result, I do not see this issue.)

I have not been able to repro this in the playground but here is the code:

//loads textures given a list of urls
function loadTexturesAsync(texturelist) {
return new Promise((resolve, reject) => {
var textures = ;

    for (let url in texturelist) {
      textures.push(new Texture(url, scene));
    }

  BaseTexture.WhenAllReady(textures, () => {
    resolve(textures);
  })
});

}

//caller
async function loadTextures(texturelist)
{
const items = ;
items.push(renderer.loadTexturesAsync(texturelist));
const values = await Promise.all(items);

//store texture in dictionary keyed by the URL
var i = 0;
const obj = {};
for (let url in texturelist) {
obj[url] = values[0][1];
i += 1;
}
return obj;
}

which in turn gets called this way:

async function loadAsset() {

const values = await Promise.all([
loadModels(modellist),
loadShaders(shaderlist),
loadTextures(texturelist),
]);

 const models = values[0];
 const shaders = values[1];
 const textures = values[2];

}

Hello! Are you able to share your code through other means, like Github? It would help us greatly in understanding what might be going on.

I hear you, let me see what I can share.

Hello Again, we have a fairly large system that would be difficult to put on github for you to test. However I was able to at least identify the culprit. After further analysis, I dont think this has anything to do with how we are loading and assigning textures as originally thought. Also this issue seems to be something with the pointer event handling under the hood and only occurs in chrome. I have tested on safari and seems to work fine. What is going on is we see a RAF Violation and a noticeable hitch in the framerate on that initial pointerdown click AS LONG AS that click happens to be on top of some geometry… like its trying to pick the geo . If we click-drag anywhere outside of the object, we do not see a frame-rate hitch and everything happens as normal. This violation warning happens even if we dont register our own pointer event. I have also tested this with the babylon default camera and same behaviour.

We are getting some warnings:
“[Violation] Added non-passive event listener to a scroll-blocking ‘wheel’ event.”

Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-unsafe-component-lifecycles for details.

[Violation] Added non-passive event listener to a scroll-blocking ‘touchstart’ event. Consider marking event handler as ‘passive’ to make the page more responsive

I saw that there was a PR for the non-passive event listener warning, but even without that fix it the warning can be ignored.

still not sure if these warnings are related to the issue.

I was going to talk about picking upon seeing your video! Checking where the warnings were leading to on the console brings us here: Babylon.js/scene.inputManager.ts at master · BabylonJS/Babylon.js (github.com), and the geometry seemed pretty complex so picking is a very likely suspect. Can you set the mesh to not pickable Mesh | Babylon.js Documentation (babylonjs.com) to see if the warnings go away?

setting it to non-pickable seems to have fixed the framerate hitch. So yes the picking was the culprit and all seems well in that department now… There is a nagging question that still remains: why did preloading the textures create a higher performance overhead than letting the textures resolve by themselves. eg using BaseTexture.WhenAllReady vs not. (picking would still have an overhead in the latter case, but the frame-rate drop was less noticeable).

Anyway, for now we are unblocked. Thanks for the help.

1 Like