Thanks Nate, this is super useful and trying it now with the next build for the game on some basic overtake screens thank you!
The worry I had is the one you mentioned where if we have more than a few webgl canvases its going to take a toll on mobile and trying to avoid that as much as possible. So for easy use case e.g. character shows up in the game, talks and leaves 1 webgl player works great.
But i want to do worst case scenario , e.g. screen has a loot box showing 10 seconds into it, character 5 seconds into it, maybe some small explosions for tiles staggered on top of items come in at 2,4,6,8 seconds in. So that would be 3 seperate spine files (player, loot box, explosions (with different timelines triggered on explosions and duplicated 4 times)
In this case it would be 6 different canvas webgls. Currently we do this with normal 2d canvases and we just spawn and do canvas draws on them then they leave. Performance has been great but its a 2d canvas library i made that i'm using for it(I made it public here https://github.com/luckyde/elCanvas)
But if this was 6 different webgls all seperately processing that would be very taxing, i was kind of picturing maybe it's a single webgl fullscreen transparent view which could spawn all 6 skeletons, animations and binaries. Then the shader could mix them(not animation wise obviously, graphics renderwing wise) So they are all rendering on the same render loop. So I could say shader.startAnim(Character).setDelay(5000), .startAnim(Particles_1).setTimeline(explode_1).setDelay(2000), .startAnim(Particles_2).setTimeline(explode_1).setDelay(4000) etc
Sudo makebelief code but does that kind of make sense? So everything still processes fast and the only high intensity thing that might happen is it would need to draw the graphics on top of themselves on every loop if they're overlapping