Pixi.js: requestAnimationFrame called by Pixi

[tobireif]

Hi Mat / Chad / Pixi Team!

Chrome reports that Pixi JS is calling requestAnimationFrame.

I'm using my own requestAnimationFrame(update). Having both seems to interfere slightly with performance. I think it would be great if Pixi would never call rAF unless when it's necessary (eg for MovieClip).

In any case: Is there a way for me to disable it?
Adding this in my JS doesn't help:
PIXI.ticker.autoStart = false;
and this is not available:
PIXI.ticker.stop();

[JiDW]

Hello,

You can do that by calling these lines :

var ticker = PIXI.ticker.shared;
ticker.autoStart = false;
ticker.stop();

And then in your own loop, call this :

ticker.update(timestamp);

Regards.

[tobireif]

Thanks, but I want to continue using my own requestAnimationFrame(update) .

And I want to be sure that Pixi doesn't call requestAnimationFrame. (if that's not possible/desired, I want to make sure Pixi doesn't call requestAnimationFrame).

[JiDW]

Yes? Well I may need to explain it in a better way but what I wrote is what you need to do that.

[JiDW]

    var ticker = PIXI.ticker.shared;
    ticker.autoStart = false;
    ticker.stop();
    function run(timestamp){
        requestAnimationFrame(run);
        ticker.update(timestamp);

[tobireif]

I want to be sure that Pixi doesn't call requestAnimationFrame.

If Mat/Chad/etc decide to stop Pixi from calling requestAnimationFrame unless required, I'll get the latest version of Pixi and be happy.

Only if they don't want to stop Pixi from calling requestAnimationFrame I'll add the code for stopping the timer (thanks for the code).

My current project doesn't have MovieClips or interactivity, so I guess I don't have to call ticker.update.

[JiDW]

Then don't call it and you'll be fine.

autostart is true by default. Changing that (meaning they think that it should be done for whatever reasons) would break every other code running pixi. Not likely to happen.

[tobireif]

No, nothing should break :) Like I wrote, Pixi should still call requestAnimationFrame when required.

Avoiding rAF calls when they're not required can only help performance, I think.

[englercj]

Pixi should still call requestAnimationFrame when required.

It is required, the interaction manager uses it. @JiDW gave you the solution like 3 times, stop the timer and manually update it in your own loop.

The reason we have it running in a separate loop is so that interaction/movieClip checks are not in the main loop (which increases performance). I seriously doubt having two RAFs decreases performance, but if you want to group it into your loop what @JiDW posted is the way to do it.

No, nothing should break :)

Of course it will, autostart is true for the interaction manager and for movieclips created to just hook into it. More importantly, the shared ticker is a _public_ api. People rely on and use it. Changing its behavior is a breaking change.

[tobireif]

It is required, the interaction manager uses it.

My current project doesn't have MovieClips or interactivity.

@JiDW gave you the solution like 3 times

Yes, and I wrote that I'll use it if necessary = if future Pixi will still call rAF.

Here's how I came across it: I hadn't known that Pixi calls rAF, investigated a perf issue, and came across Pixi's rAF calls in exactly the low-FPS regions of the Chrome timeline. I don't know how severe the perf impact is, but it was always listed among the various calls in the problematic timeline regions.

Here's a copy of the unfinished demo:
http://tobireif.com/non_site_stuff/copy_of_unfinished_pixi_demo/1_webgl_2d/

In the above demo, Pixi is calling rAF (reported by Chrome's timeline) although there's no interactivity and no MovieClip.

I think that when there's no interactivity and no movie clips, Pixi shouldn't call rAF - that could help performance. (And when the user creates interactive items or movie clips, Pixi would start the rAF loop).

But the decision absolutely is up to Mat / you / etc.

More importantly, the shared ticker is a public api. People rely on and use it. Changing its behavior is a breaking change."

People could still use it - it would have to start running as soon as the API user calls eg ticker.add(...) (it would be one of currently three reasons for starting the ticker.) (If it gets implemented like that, there also should be an option to set eg .neverStart = true.)

Another aspect to consider is that many users don't know that Pixi is running an rAF loop, and thus can't consider whether they want to turn it off.
That's why I think it should only start running when necessary.

I hope you understand my suggestion, and that it is potentially good for performance in all Pixi apps (not just in mine). It seems possible to implement it without breaking anything - in that case please consider it.
If you decide against it, please close the ticket, then I'll stop the Pixi ticker in my code (and call PIXI.ticker.shared.update(timestamp) from my rAF loop if necessary).

[englercj]

People could still use it - it would have to start running as soon as the API user calls eg ticker.add(...)

That is what it does right now when autoStart is true, which it is by default. If we make autoStart instead false by default, then people's code will break until they realize they have to manually start the ticker now.

That's why I think it should only start running when necessary.

I already does :) The interaction manager is using it so it runs, though the callback it calls does nothing because there are no interactive elements. If you don't use the interaction manager, then get rid of it:

renderer.plugins.interaction.destroy();
renderer.plugins.interaction = null;

The interaction manager will shutdown, remove its events, and the Ticker will go to sleep since it is no longer used. There is no way to know when the interaction manager should run and not. There is no event or notification of something becoming interactive. So the only way to know when something becomes interactive to be checking for it the way it does now.

I don't know how severe the perf impact is, but it was always listed among the various calls in the problematic timeline regions.

I can't find anything the timelines or profiles that would suggest that the RAF used by ticker takes any more time than 1ms. Can you post an example of what you are seeing? According to my timeline the RAF from the ticker takes ~0.06ms, so I'm not sure what the problem is.

It seems possible to implement it without breaking anything - in that case please consider it.

Possibly, but that would involve some serious rewritting of how the interaction manager works, and how making things interactive works. We may do that at some point in the future, but it is very unlikely to happen any time soon.

then I'll stop the Pixi ticker in my code (and call PIXI.ticker.shared.update(timestamp) from my rAF loop if necessary).

If you have no movie clips or interactivity, then no need to call it. All you want to do in your app is just stop the ticker (or stop the interaction manager and the ticker will stop itself).

[englercj]

Closing since this seems answered.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.