Search the Community

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? https://imgur.com/a/8Uh8028

Has anyone ever seen this where my RAF wants to take up the entire frame (~15ms) but the processes within don't take very long (~3ms)? My app is running iOS on Cordova with wkwebview. Long RAFs: https://imgur.com/a/2KVeKJZ Processes within one RAF: https://imgur.com/a/CnUNSfk BUT When I zoom into the canvas (by doing the two finger swipe on the iPad) and then zoom out, the RAF fixes to take up only ~5ms total. After zoom trick: https://imgur.com/a/RSzmrTI Is the PIXI canvas loosing focus, like as if I went to another tab on the web? I'm not sure what is happening here, thanks for any help! ?

Hello, I'm having issues running PIXI with an autoDetectRenderer in Cordova iOS. It is very slow compared to just loading the page from Safari within iOS. The goal is 60fps but Cordova is getting ~25fps while Safari has performance that is good enough to be acceptable. Is there some kind of optimization I have to turn on? The cordova docs claim that the hardware acceleration config option is only available on OSX, not iOS. I ensured that my game loop function usually takes about 1-5 milliseconds to run in Cordova. Could it be some kind of overhead that Cordova has set up with plugins or something? The only cordova plugin I'm using is one that I created myself, which takes event input from an external musical bluetooth MIDI controller. My app is essentially a rhythm game with a big highway of arrows moving as one container with animated sprites that flash at different times and hide/show accordingly to how you played. How do I get comparable performance to iOS Safari on iOS Cordova with PIXI? (Btw using React to bundle and build all this). Thanks! ? Cordova docs: https://cordova.apache.org/docs/en/latest/config_ref/

Greetings! I am working on a horizontal scrolling rhythm game in React that uses Pixi for generating sprites. I want to use PIXI.ticker.elapsedMS to determine when a new sprite should be created and how far it should move its x position to stay in time with the song. My issue is that ticker.elapsedMS is taking longer than the expected millisecond value for a single frame at 60 fps. Is this expected behavior for ticker.elapsedMS to fall behind in a simple example like this? import React, { PureComponent } from "react"; import { css } from "react-emotion"; import * as PIXI from "pixi.js"; import "pixi-layers"; export default class PixiHighway extends PureComponent { constructor(props) { super(props); this.pixi_container = null; this.expectedFPS = 60; //assuming we're at 60 FPS this.expectedMSPerFrame = 1/this.expectedFPS*1000 //roughly 16.67 this.app = new PIXI.Application({ width: 1200, height: 800, transparent: true, backgroundColor: 0xffffff }); this.app.stop(); this.app.stage = new PIXI.display.Stage(); this.app.stage.group.enableSort = true; this.startSongTime = 0; } updatePixiCnt = element => { // the element is the DOM object that we will use as container to add pixi stage(canvas) this.pixi_container = element; //now we are adding the application to the DOM element which we got from the Ref. if (this.pixi_container && this.pixi_container.children.length <= 0) { this.pixi_container.appendChild(this.app.view); } }; update = delta => { this.now = new Date().getTime(); const songElapsedTime = this.now - this.startSongTime; if (this.app.ticker.elapsedMS > this.expectedMSPerFrame) { console.log( "WARNING Under 60fps! elapsedMS:", this.app.ticker.elapsedMS, "deltaTime:", this.app.ticker.deltaTime, "Dropped frame this far in ms through the song:", songElapsedTime ); } }; startTheTicker = () => { this.app.renderer.plugins.prepare.upload(this.app.stage, () => { this.app.start(); }); this.startSongTime = new Date().getTime(); this.app.ticker.add(this.update); }; render() { return ( <div> <button className={css` position: absolute; top: 900px; `} onClick={this.startTheTicker} > Start animation </button> <div className={css` position: absolute; z-index: 2; `} ref={element => { this.updatePixiCnt(element); }} /> </div> ); } } Here's the result of the console.log when this.app.ticker.elapsedMS > this.expectedMSPerFrame. Is the log just slow or is my ticker being run incorrectly? Thanks for your time!

Android stock browser has a bug that causes the RAF to freeze when it loses focus, even it the tab gains focus again. I created a workaround for this, forcing raf.stop(); and raf.start(); everytime the tab gains focus. This workaround worked fine until I updated some games to version 2.3, then it crashes games with the following error: Uncaught TypeError: Property 'cancelAnimationFrame' of object [object DOMWindow] is not a functionI checked the RequestAnimationFrame update history, and nothing has changed there in version 2.3, but the same game doesn't have this bug with older versions. Any idea on why this may be happening just with 2.3?

is your requestAnimationFrame dated? http://paulirish.com/2011/requestanimationframe-for-smart-animating/http://my.opera.com/emoller/blog/2011/12/20/requestanimationframe-for-smart-er-animating (this link doesn't work properly) When reviewinghttp://updates.html5rocks.com/2012/05/requestAnimationFrame-API-now-with-sub-millisecond-precision which references High Resolution Timehttp://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html#sec-extenstions-performance-interface The paul irish blog seems to have posted some revisions.. removing the o and ms vendor tags.. but it isn't reflected in his git distribution.. and some of the year old comments make reference to the performance.now() (High Resolution Time) methodology.. and discuss mozilla date.now() issues.. 16.7 ms seems to be the ideal timing.. which I suspect is only possible with the HDT precision.