I guess you've read the blog post on spritesheets, although some details have changed (it now goes up to 2048x2048 instead of 512x512 for example).
I agree the progress bar argument isn't really that relevant, but there are other significant considerations. It is a surprisingly difficult area with some interesting tradeoffs. One of the tradeoffs is compatibility with existing plugins, which is why currently only Sprite animations are spritesheeted. It's difficult to make changes to C2 at this stage, but I think we will make some improvements in this area for Construct 3.
Here are some other factors that impact how spritesheets work:
- Construct 2 automatically optimises images to PNG-8 when there are under 256 unique colors. The more images on a sprite sheet, the more likely it is to go over 256 colors. Therefore increasing the size of spritesheets can increase the download size.
- The canvas2d renderer does not support rotated source images, which it looks like Texture Packer uses. WebGL can support this, but right now for compatibility with canvas2d images cannot be rotated to improve packing. I want to ultimately drop the canvas2d renderer, but now is too soon.
- When downscaling images a long way, it is necessary to pad images out to power-of-two offsets in the sprite sheet to prevent mipmap bleed (which appears as thin lines appearing along the edges of downscaled images). This reduces the packing efficiency and increases memory use, but is mandatory to completely rule out this type of glitch and is why the "high quality" downscaling option exists. (I don't know if Texture Packer supports power-of-two alignment)
- The performance test I use (an automated version of Space Blaster) is a pretty realistic test I think, and the framerate is the most important performance indicator. It does include GPU throughput, it is not a CPU-only measurement. When experimenting with the different spritesheeting strategies, I literally measured zero performance difference, even on an older mobile device (an iPad 2). I think modern drivers and GPUs are pretty good at swapping textures, and the main optimisation is actually a CPU optimisation so it doesn't have to issue "set texture" instructions, but that is pretty much a micro-optimisation and probably the least of all the concerns here. I do not believe there is any important GPU performance difference using individual images, one gigantic spritesheet, or anything else in-between.
I also have no idea why you would ever want to manually intervene in the layout of the spritesheet. It seems to me almost completely pointless: they will have to be re-layout every time you add, remove or change an image, or even just changing some project properties causes a global spritesheet re-layout (such as changing the downscaling quality to/from "high quality"). If you manually put an image in some position on a spritesheet and then you change something else, the editor has two options:
1) absolutely rigidly for all time insist that the image appears on the sheet where you put it. This is ridiculous, because it will reduce packing efficiency, since after a few edits it may save a lot of space to pack it somewhere else.
2) do the automatic re-layout again and revert your changes. This makes it pointless to have a feature where you can change the layout of the spritesheet.
Neither seems sensible, so I don't think it's worth having as a feature. C2's sprite sheet packer may not be perfect, but I think it's at least OK, it does the job of saving memory, and it does it automatically so you don't need to worry about it.