InteractionManager.update() is coupled to render() loop?

[inductible]

Hullo, 

 

from my tentative investigation, it would appear that the InteractionManager's 'update' method (which I presume is where the magic of input event marshalling takes place) occurs within the scope of renderer.render() - certainly for the canvas renderer anyway.

 

What I'm trying to do is get my Pixi based system set up to smartly render *only when necessary*, i.e. when the view state is deemed 'dirty'. This is due some audio performance issues I believe are related to canvas redraw... But, in the greater scheme of things it would be cool to be able to have my cake (Pixi interactivity) and eat it (skip rendering, if I want to).

 

Before I start hacking this in at Pixi's source, I wondered (Matt!) is this something you've thought about? At a very quick glance I don't think it'd be difficult to move the interactionManager update out of the render loop, but it'd be a powerful improvement.

[xerver]

We have plans to separate the InteractionManager completely from the pixi core. Right now however, that is the way it works; it is updated via the render loop.

 

What is your FPS that makes you think you have audio issues due to canvas redraws?

[inductible]

I ended up tweaking Pixi to open up a new 'updateInteractionMangerOnly' func, then recreated my issue with rendering effectively suspended: conclusion - my audio skippage is not related to Pixi redraw. I think it may be limited to my audio system (a custom sprite based audio tag affair), but HTML 'Audio' tag is so screwed up the spout that that's no surprise. I know there's a ton of unspoken implementation specifics here, so I won't dwell on the issue - it'll be something to do with something elsewhere!

 

Thanks indeed for the notice about plans with interaction manager - that definitely sounds like something to look forward to... +1!