Search the Community

Hi Everyone, I'm working on a Guitar Hero / Rocksmith like game in Pixi.js: a song plays and some boxes scroll towards a cursor that lets a guitarist know how to play along. Website if anyone is interested: aimusiclessons.com. I'm running into performance issues, specifically with stutter and after 1.5 weeks going through PIXI issues and HTML5 dev forums and trying a bunch of different approaches I'm completely lost with what to do next. The stutter really impacts UX and my sanity. Any help/guidance would be greatly appreciated. There's no crazy animations, filters, or massive amounts of sprites, so it should be running smooth even on a crappy device. For the experiments below I removed all the microphone monitoring and processing, it's just straight up PIXI and Howler (playing the mp3 file). Example video of stutter issue (sorry for Justin Bieber - I'm sorry too, it's been my test song for 1.5 weeks). app_stutter_example.mp4 I'm developing in Chrome (other browsers affected as well): dev tools says 60fps and no dropped frames, all render ticks are happening well within 16.6ms acceptable bounds. Mobile performance has stutter too, and lower fps ~40fps. I've tried 2 different approaches to drawing boxes (boxes are variable width, so need to be scalable). There's max 15 boxes on screen at a time and max maybe 3000 boxes total in a 3.5min song. Each box is Pixi.Container containing a graphics object drawing roundedRect for the foreground, roundedRect for the background shadow, Pixi.Text for the number. I read there's a potentially a bunch of performance issues with Pixi.Graphics so I've also tried calling cacheAsBitmap on each box after assembling it when loading the stage to try to speed up rendering later on: seems to be a bit more stable in terms of stutter than my other attempts but still noticeably bad. I also don't love this approach because I need to change the box tint realtime and then need to disable cacheAsBitmap then re-enable which seems inefficient. ^ this is a frame that takes longer to render (some take 2ms, some 9ms like this one). With this approach, relatively low GPU usage (GPU tasks are each under 1ms), 60fps (we don't drop a frame), but stutter exists I think because variability in length of time to render frame. Don't appear to have bad GC calls. I found this post that Ivan responded to that suggests a sprite for the left of rounded rect, sprite for middle, and sprite for right of rounded rect. I created images in a sprite sheet for the left, middle (1px), and right of the boxes (sprite for each) and then setting .width on the middle sprite (tried both Sprite and TilingSprite) to have variable width boxes. Instead of using Pixi.Text, load image of text number from spritesheet. Stutter still exists. No bad GC calls. ^ with this approach all the frame renders seem to be much shorter (<2.5ms each). In other performance snapshots I saw longer GPU tasks in bad stutter sections (some up to 10ms long), but can't recreate that today. Edit: was able to recreate it this morning, here's the performance snapshot (see the bunch of grey peaks in the timeline corresponding with long GPU tasks): Here's Spector.js rendering out a frame I've tried 2 different approaches to scrolling, culling: Putting all the boxes into one Pixi.Container. Changing the x position of the Container every tick to scroll all the boxes over. Culling algorithm runs every mod 15 frames that sets .visible/.renderable on off-screen boxes. Pooling: constructing a pool of 20 boxes on load and request/releasing them in culling algorithm when they would be on screen. Swap texture for text number I need. Set width (stretch) middle sprite to have the correct width box. Scroll by changing x position of each active box on stage directly: ~15 DisplayObject position updates per frame. Other things I've tried: Seemingly every combination of PIXI.settings (antialiasing, resolution, GC_MODE, ROUND_PIXELS, etc.) https://github.com/pixijs/pixijs/issues/7771: I do subclass PIXI containers and Sprites in my OOP code. I painstakingly changed that structure and it didn't help. Removing every object/widget on the screen except for the background guitar fretboard and the scrolling note boxes. Still stutter. Using pixi preloader (although I think loading BaseTexture from sprite atlas loads up the GPU anyways so redundant). POT spritesheet to enable MIPMAP. I ran into a bunch of issues with artifacts on the screen, but still didn't help stutter. Disabling all browser extensions running There's no transpiling happening with Babel, etc. I just want this thing to run smoothly. It should be able to and that's why I'm frustrated (and length of time debugging this). I created a CodePen with a minimal example that demonstrates the stutter: https://codepen.io/gburlet/pen/QWqxxLE. This uses @ivan.popelyshev's idea of rendering variable length boxes with 3 sprites and culls using a Sprite pool. If you sit and watch the movement, sometimes it's smooth and then stutters here and there, and sometimes gets into bad sections of stutter then recovers, at least on my macbook, mac pro, iPad, iPhone (all > 2017 devices). On my beefy gaming computer with nvidia card seems to run OK. Any suggestions, guidance, advice, help? Thanks!

Hello, html5 freaks I trying to make idle game using pixijs, but when I put animated sprite that is 1024x512 in size it freeze game short time. From profiler I saw that texImage2d took 180ms and from that 104ms was imageDecode. I read somewhere to preload the animations before hand and just make them visible when needed, but it didn't work and same texImage2d happend. How I can prevent that other than downscaling the sprite? Also is there possibility to do that in webworker? I read somewhere that pixi is starting to be capable of rendering on webworker. Cheers, Jakub

Hello everyone! I have a big map with a tilesprite in the background (repeating mountains). When I want to hide them, the first time I do background.alpha = 0, I notice a huge stutter. I can go back to alpha = 1 and alpha = 0 as much as I want later on, no issue. Only the first alpha = 0 causes the game to lag terribly. I have tried with visible, renderable, exists etc. : same result! I have also tried to create a tilesprite with different frames and switch between them, but the impact on performance was dreadful (lost 50FPS!). How could I avoid that? What's the cause of this stutter? Thanks a lot!

I'm doing a small animation test, and even the simplest animation seems to stutter? What am I doing wrong? Have a look here: http://christianlaumark.dk/Portfolio3/test2.html //Avatars var Container = PIXI.Container, loader = PIXI.loader, Rectangle = PIXI.Rectangle, Graphics = PIXI.Graphics, Sprite = PIXI.Sprite, resources = PIXI.loader.resources; //Setting the stage var stage = new Container(); var myView = document.getElementById('main'); var renderer = PIXI.autoDetectRenderer(window.innerWidth,window.innerHeight,myView); renderer.view.className = "rendererView"; document.body.appendChild(renderer.view); var wW = window.innerWidth; var wH = window.innerHeight; loader .add([ "images/portfoliozepper.png", "images/bg.png" ]) .load(setup); var dir = "right"; var bob = "up"; function setup() { console.log("starting setup"); bg = new Sprite(resources["images/bg.png"].texture); zep = new Sprite(resources["images/portfoliozepper.png"].texture); bg.position.set(wW/2,wH/2); bg.anchor.set(0.5,0.5); bg.scale.set(2,2); zep.position.set(100,wH/2); zep.anchor.set(0.5,0.5); zep.scale.set(-0.5,0.5); stage.addChild(bg,zep); state = idle; gameLoop(); } function gameLoop() { requestAnimationFrame(gameLoop); state(); renderer.render(stage); } function idle() { if (dir == "right") { if (zep.x < wW) { zep.x += 1.5; } else { dir = "left"; zep.scale.set(0.5,0.5); } } else if (dir == "left") { if (zep.x > 0) { zep.x -= 1.5; } else { zep.scale.set(-0.5,0.5); dir = "right"; } } if (bob == "up") { if (zep.y > wH/4) { zep.y -= 0.5; } else { bob = "down"; } } else if (bob == "down") { if (zep.y < (wH/2 + wH/4)) { zep.y += 0.5; } else { bob = "up"; } } }

I've just ported the key bit of a game I'm working on from HaxePunk to Phaser and am having a problem. As my main sprite moves it stutters, judders and in general does not move with the silky smooth motion I am expecting. You can have a look at it in action here: http://www.mountainstorm.co.uk/test/ZD/ I've tried both Chrome and Safari on OSX and both seem to have the same issue. I've also tried commenting out more the code (so it just moves the sprite at a programmed constant rate) and it's still not smooth. I've also tried playing around with calculating the motion based on elapsedMS, elapsed and physicsElapsed and none seem to make much difference. My CPU only runs at about 20%, so I'm kind of at a loss as to whats going wrong. Anyone have any thoughts?

Hey everyone, first of all - thanks for PhaserJS. It's awesome and I love working with it. I'm working on a game called rocklegend - which is available here: http://rocklegend.org - currently to see the game you have to login. I created a user account for you guys to test: Username and password: phaserjs I optimized a few things such as the notes (only drawing a fixed amount of notes at the same time, so I have 20 notes and reuse these objects)... But currently I can't find out why the game still feels laggy sometimes. The notes are positioned within a Group Container and the containers y position ist updated in each update call according to the playback position of the played song. I'm not sure if the problem is the sound library - I'm using SoundJS for the sounds - should i try lowlag maybe, or if it's my code that's not optimal... You can find the concatenated version of the JS at http://rocklegend.org/games/note-highway/develop/player/build/game.cat.js Any advice, hints, ideas are greatly appreciated! Also, if you just have tips how I could try to debug this problem, that'd be great

Hello everyone, I've been having issues the last couple of days, because the arcade physics seem to be working unreliably in firefox. I have had no problems and no failures with it in Chrome. In firefox every now and then the game lags (more of a stutter, very short freeze) and the arcade-physic collision detection fails. I can walk through walls, fall through the ground and jump through ceilings. Looking at the framerate reveals a small drop in framerate whenever this happens. I also noticed that in Chrome the framerate stays more stable and the problem never happened so far. Looking through the issue tracker on github also didn't reveal anything in this direction. Can anyone help me with this?