— - the thread you linked to, apart from having quite a lot of confusion over how WebGL rendering actually works, is a good demonstration of the tradeoff. Conceptually we can imagine either extreme:
Maximum spritesheeting - there is a single gigantic spritesheet that contains all the images in the entire game.
Pro: the entire game can be rendered without ever switching texture. In ideal circumstances, this means a single draw call can draw everything! (Although things like opacity, blend mode, effects etc. will "break the batch" and add more draw calls)
Con: the game always uses the maximum amount of memory. There is no possibility for memory management - either everything is loaded, or nothing is. For large games this means they may not be able to run at all if there is not enough memory.
Or: maximum memory efficiency - every single image is a separate texture.
Pro: minimal memory use, since memory management is effective at ensuring textures which are not needed are not loaded.
Con: maximum draw call overhead - every time a different image is drawn, it must switch texture.
You can't have it both ways - this is a tradeoff between each extreme. I think the maximum spritesheeting case is worse than the maximum memory efficiency case, since the game can fail to run at all if it doesn't fit in memory. On the other hand the maximum memory efficiency case may be slower, but at least it can run.
Neither C2 or C3 actually does either of those extremes, but C2 is closer towards the maximum memory efficiency end, and C3 is closer towards the maximum spritesheeting end.
Taximan sent me their project by email which I am using to guide changes to the spritesheeting algorithm. In the case of their project, there was a signficiant increase in memory usage between C2 and C3, and it looks big enough that it may prevent some devices from being able to run the game at all. So I think it's good evidence we need to move back further the other way. In theory this could increase the draw call overhead, but as ever if people send me actual projects I can use them for testing and optimisation as I am doing with Taximan's project; otherwise I can only speculate. We do have some more changes in the pipeline though that should help both memory usage and draw calls, as well as giving more control over the spritesheeting process.