Thanks for that example Arima, very helpful. I see how your animation gets cropped and plays back properly without jitter. I will figure out how to align my pre-rendered 3D frames/origin similar to your 2D artwork. Thanks again, this will be a nice savings.
Great, glad it helped!
I would be very interested to see 
Ashley comment on this thread. The example given going from 8mb ram to 1mb is a very compelling reason to at least look this possibility. I have had projects where the artwork was too much for a number of devices and looking at the exported images there certainly appears to be scope for improvements to the memory usage.
Cropping should fix that problem.
Here is an example from an export two buttons only 128x64 are stored on a sheet 256x256. At this size it isn't a major but it is principle, I expected the packer to be more efficient.
I'm guessing that's because of C2 adding a 1 pixel border when cropping to get 'free' edge antialiasing. If you resize the image to 126x62, does it work?
I never said it was the best way to do it, but it is capable of doing it, with the addition of the ability to define hitboxes and sound triggers in Spriter.
Ah, I misunderstood your point.
That depends on how it's rotated and how often. If it's rotated in-game by rotating the sprite, then it needs to do that, along with resizing the sprite if the images are different sizes, every frame. Saving memory and still ending up with a potential framerate drop is not exactly a positive tradeoff.
If it's rotated in memory, that makes rotation dependent upon the GPU, and since C2 strives to support non-WebGL accelerated devices as well, chances are it'd have to create a copy of the original sprite, rotate it, then remove the original sprite from memory - which would most likely involve rewriting how C2 handles images in memory, keeping in mind that when not using WebGL it loads all images from the project at once, and the memory spikes that would be caused by rotating images at runtime could push many mobile games over their limit. And that all assumes that HTML5/JS, outside of full hardware-accelerated WebGL, even has the capabilities to do it quickly. Which is questionable.
That's actually not how it works. Think of it like this: you have a piece of real world paper, and a stamp. It doesn't matter what angle the stamp is at when it touches the paper - the gpu calculates it in real time when drawing the pixels, and needs to make no modification to the stamp itself to do so, and it incurs almost no performance hit in the process, because gpu makers have optimized the operation like crazy.
If it worked the way you suggested, practically no 3d game would be possible because every single texture on every polygon of every model is being distorted in an uncountable number of permutations based on perspective, angle and animation. It would use a ridiculous amount of memory to do so and would be completely pointless as very little of the saved work could be used ever again. Even if instead of saving an extra copy of the texture it just overwrote the original, the quality of the texture would degrade as it got blurrier and blurrier from being filtered over and over again.
Also, when not using webgl, canvas2d is used which is still hardware accelerated, just not as efficiently. Even software rendering such as chrome uses still doesn't need to use more image data in memory to rotate a sprite because it emulates the real time process hardware acceleration uses.
That's making an assumption in terms of GPU power, and I'm still not buying that there would be any significant memory savings - while not impacting other areas - by doing so.
That's why I said it could be an option.