Jump to content

Long RAF execution behavior in Chrome devtools


Recommended Posts

I'm getting a lot of inconsistencies in fps due to requestAnimationFrame calls randomly taking a long time where it doesn't look like there is anything being called inside of it until the tail end of the call. What it does show in the call tree only takes PIXI 1-3ms to flush or update transforms while the RAF call can last anywhere from 8-15ms. The devtools are also showing that the GPU and other threads aren't doing any irregular work when the long RAF call happens. It happens at least 10-20 times within a 30 second Chrome devtools performance recording. Has anyone else experienced this kind of thing before? 


Link to comment
Share on other sites

If Pixi playground still isn't showing up for you then delete all the code and put this in x)

/*pixi playground consistant transform test*/
var img = document.createElement("img");
img.src = "https://i.postimg.cc/MKDkHyGN/background-Spice.jpg";
img.style.position = "absolute";
img.style.zIndex = -2;

var totalTimePassed = 0;

//webgl renderer
var renderer = new PIXI.Renderer({
    width: window.innerWidth,
    height: window.innerHeight,
    transparent: true

var stage = new PIXI.Container();

var loader = PIXI.Loader.shared;
loader.add('bunny', 'https://pixijs.io/examples/examples/assets/bunny.png')

function startup(loader, resources)
    var bunnyContainer = new PIXI.Container();

    //make 300 bunny sprites at the edge of the pixi canvas
    for(let i = 0; i < 300; i++){
        var bunny = new PIXI.Sprite(resources["bunny"].texture);
        bunny.visible = false;
        bunny.msUntilStartMoving = i * 1000;
        bunny.x = renderer.width;
        bunny.y = renderer.height / 2;

function animate(delta) {
    for(let i = 0; i < stage.children[0].children.length; i++){
        //Once enough time has passed kick the next sprite into moving
        if(stage.children[0].children[i].msUntilStartMoving < delta 
            && stage.children[0].children[i].x >= 0)
            //unhide sprites at the edge to get ready for transforms
            if(stage.children[0].children[i].visible == false){
                stage.children[0].children[i].visible = true;
            //consistantly transform x
            stage.children[0].children[i].x -= 3;
        //once they make it to the left side of the screen, visible false for no transform overhead
            stage.children[0].children[i].visible = false;


Link to comment
Share on other sites

Sorry I didn't really specify before @Exca, the screenshot in my first post is a part of the profile of my full game which uses the same code setup for consistently moving x values, just with more sprites. ? The moving parts are all the numbers and sprites in the middle section https://imgur.com/a/hhhIavE. I made the PIXI playground example and saw that it was also having some stutters for a much more simple version of my game so I figured it must've been an issue with how I was doing it. ^.^ Here's some more profile data on the pixi playground example to try and see similar issues! ?

30 second profile #1:

As Exca mentioned, I am seeing major GC happening a few times in the beginning of the example and then it stabilizes.

Longest major gc: https://imgur.com/a/LDklp5o 

4 main gc in beginning 25 seconds https://imgur.com/a/ODOoCL0


30 second profile #2:

I got something similar to what I see in my game, where the request animation frame seems to take up a lot of time (19.62 ms) without really doing anything. https://imgur.com/a/UARFcMb

I've seen both of these types of slowdowns in my game too, any advice? ?

Thank you!

Link to comment
Share on other sites

Yes good idea! I turned off all my plugins for Chrome on my Macbook Pro and I haven't gotten a profile with a RAF failure in 3 separate 60 second profiles.

However, I still see it happen in my game ? My guess is that since an RAF is supposed to sync with the browser, Chrome is saying that it's not ready to draw yet and holds the RAF up until it is ready. Or maybe my Macbook Pro isn't giving Chrome the resources it wants to be able to draw again too when the temp rises and fans start up.

To test this, I did a profile on my Chromebook with the Pixi playground example and saw many slowdowns, most of them GPU related or caused by large spaces between frame executions. Also some GC. It is obvious that a Chromebook should perform much worse, but maybe it's highlighting the main problem to be with the Chrome browser itself or more of a device specific GPU + CPU available resources type of issue. 




Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...