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? 


Share this post

Link to post
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;


Share this post

Link to post
Share on other sites

Yeah, but heap size looks like it changes in that frame on the memory graph. So something happens with memory. Though it should have a node with carbage collection if actual gc happens.

@ZYandu Can you take a profile of the posted example when stutter occurs?

Share this post

Link to post
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!

Share this post

Link to post
Share on other sites

Very mysterious indeed. Especially the second animation frame delay. Do you have lots of console.logs? Though if that was the case, then the problem would disappear when dev tools is closed (at least on windows).

Share this post

Link to post
Share on other sites

I think the first few GC's are something related to loading of the pixi playground as those I can get too. After the GCs though the rendering continues without a problem.

For some reason I cant upload a screenshot of the profiler. But here's a link to my profiling: https://imgur.com/wtTMvqX

Do you have some plugins installed?

Share this post

Link to post
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. 




Share this post

Link to post
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.