Rob Gordon

  • Content Count

  • Joined

  • Last visited

About Rob Gordon

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Just adding a quick note that this has now been addressed in the PIXI source code:
  2. I know this has come up in the past...but is there a 'best-practice' implementation of a Howler integration with PIXI v5 (including integration with the loader) that anyone can share? The few hits I see in the forum are a bit outdated. I have already (successfully) used pixi-sound...just want to compare... Cheers!
  3. Thanks Ivan - good luck with the release!
  4. Understood - though this is the kind of thing that should probably be reflected in the documentation (RenderTexture is a major feature, imo). Do you know if this is slated for the upcoming 5.3.0 release? I would think having parity between WebGL & Canvas would be critical. Anything you can share from your custom implementation? Is it as simple as removing the check for this.renderingToScreen, or will that break things?
  5. There appears to be an issue with clearing the context when rendering a container to a RenderTexture while using the CanvasRenderer (PIXI-legacy v5.2.4). Consider this example: Click anywhere to toggle the visibility of one of the bunnies. Using the CanvasRenderer the context is not cleared, and the bunnies remain visible. Using the WebGL renderer (switch forceCanvas to false) this works as expected. I believe the issue may be here: if (clear !== undefined ? clear : this.clearBeforeRender) { if (this.renderingToScreen) { if (this.transparent) { context.clearRect(0, 0, this.width, this.height); } else { context.fillStyle = this._backgroundColorString; context.fillRect(0, 0, this.width, this.height); } } // else { // TODO: implement background for CanvasRenderTarget or RenderTexture? // } } The 'TODO' needs to get done. It appears there is no context management for the case where we are not renderingToScreen (as I believe is the case when we are rendering a Container to a RenderTexture). ** I've posted this to the github issues, but thought it might make sense to post it here as well to ensure that this isn't an error of understanding or implementation on my part...
  6. Thanks Ivan. I've cooked up a solution that works well enough for now and I wouldn't want you to waste time (rather save that for when I'm really stuck!). Here's what I'm presently doing: renderTextureSprite = new PIXI.Sprite(PIXI.RenderTexture.create({width:mywidth, height:myheight, resolution:myresolution})); ...then for each sprite I create a shadow (copy of the sprite, tinted black, alpha of 0.4, blur filter applied) and render it: renderer.render(shadow, renderTextureSprite.texture, false); ... and then render the sprite: renderer.render(sprite, renderTextureSprite.texture, false); The advantage is that I can spread the work out and show a progress bar along the way. I'm happy to hear other ideas for how to do this (and learn more about PIXI), but for the moment this is working nicely.
  7. BTW - I can confirm that the performance of doing a manual renderTexture with the DropShadow filter applied is awful. Switching to using twice as many sprites with every other one being essentially a blurred black-tinted copy of its neighbour is considerably better. Since Blur and DropShadow are rather similar it seems what we really need is a performance DropShadow filter (preferably build into PIXI). Still hopeful there's a better way... UPDATE: just realized you can build up a renderTexture progressively by passing false as the 3rd parameter. I think that may be the answer...t least I can spread the work over a number of ticks/frames...
  8. >> Setting cacheAsBitmap to true for the container is considerably faster > It looks like cacheAsBitmap is also using a renderTexture for this operation. When I do this that way directly the operation is quite slow. Why would this be? >> Some of these things are known issues (though the filter rendering problem feels like a bug of cacheAsBitmap). >We fixed it sooo many times, maybe it actually works now, try I'm using v5.2.3, Is there something newer? > Is there a better approach here? >>Yes, but it depends on your case. I know many tricks for advanced users >>DropShadow is very slow, Blur is faster of course and I usually use DropShadow based on blur. Well...none of the sprite are interactive or animated. It's really just a complex background image made up of 100s of individual pieces - each requiring a dropshadow. I could build it up progressively in canvas - but would prefer to keep it all within PIXI if I can. Cheers!
  9. I have a Container with ~700 sprites in it, each with a filter applied (I have tried both dropShadow and blur). Obviously that's too many to render on stage. Creating a renderTexture works perfectly - but it's a very slow process to create it, and I worry about the impact on lower-end mobile devices. Setting cacheAsBitmap to true for the container is considerably faster - but doesn't seem to support either the dropShadow or blur filters that are applied to the individual sprites. Some of these things are known issues (though the filter rendering problem feels like a bug of cacheAsBitmap). Is there a better approach here?
  10. Right. Don't generally need that (but I can see how it can come up for others).
  11. I may have just answered my own question. It seems the InteractionManager doesn't NEED PIXI.Ticker.system, but can send it events and is set up by default to do so. You can do this to shut that down: app.renderer.plugins.interaction.useSystemTicker = false
  12. Greetings, I'm trying to understand what PIXI.Ticker.system actually does. I have experimented with doing the following after initializing my application: PIXI.Ticker.system.autoStart = false; PIXI.Ticker.system.stop(); The result is much less energy use (as measured by the Activity Monitor in OSX) and no change in the functionality of the application. The docs mention it's used by PIXI.interaction.InteractionManager (which I use a lot), but all my functionality is intact. FYI, I'm also stopping the shared Ticker and just using app.ticker for everything at maxFPS of 30. Thanks, r o b
  13. Thanks Ivan. I had looked through the EventEmitter3 source and I believe I understand why it works this way. I can absolutely work with/around it - so I wouldn't say this is really needed at the moment. It's probably good practice to keep track of event states anyways... I would have liked 'removeAllListeners' as a convenience feature to really clean out all events from the target (InteractionManager in my case). Would make my code a whole lot cleaner. On my current project i have many interactive I try to keep their events 'off' until they are activated/required. I have found that too many listeners at once can really slow things down. Cheers!
  14. Question about the InteractionManager: The following works as expected: InteractionManager.on("pointerdown", handlePointerDown); function handlePointerDown(e) {"pointerdown", handlePointerDown); console.log("hello",; } console: "hello" 1 The following adds the event twice (I would have not expected that to happen with the same event/function): InteractionManager.on("pointerdown", handlePointerDown); InteractionManager.on("pointerdown", handlePointerDown); function handlePointerDown(e) {"pointerdown", handlePointerDown); console.log("hello"); } console: "hello" 1 (2) Even with the issue above, I would have expected 'removeAllListeners' to eliminate the second call, but it does not: InteractionManager.on("pointerdown", handlePointerDown); InteractionManager.on("pointerdown", handlePointerDown); function handlePointerDown(e) { InteractionManager.removeAllListeners(); console.log("hello"); } console: "hello" 1 (2) Is this the way this stuff is supposed to work? I could certainly manage all events very explicitly...but it would be so much simpler to be able to 'removeAllListeners' when needed instead of using 'off' for every single event. Cheers, r o b