This is another post that was going to be an in-thread response to a review but I thought was too good a cautionary tale not to share. It's technical but a good lesson of a blind spot.
I uncovered this last week as I was wrapping up some animation examples. My very carefully crafted binary document format, with optimised length numbers and bit flags all over the place ... only stored positive numbers.
That's not a big deal if you're doing things within an iPhone screen (or storing counts). But, doing a fancier animation sample which had a cube shrink and dart off-screen, to slowly re-appear, made me realise:
1. If you have movement directions, sometimes they are going to be negative.
2. It's completely valid to have the origin of an element be off the side of the page, especially if it's going to move later.
That kind of derailed my week with a cascade of changes and looking again at other assumptions I'd been making.
Lots of unit tests later, very happy with the results and it squeezed in with almost no overhead unless you use negative numbers. (eg: anchoring an element off the topLeft corner with an 8 pixel padding is encoded in 1 byte but if you make that -8 pixels it suddenly jumps to 4 bytes).
If you're not a low-level programmer, I'll explain a bit more. Just casually saving the numbers which are used in memory means a single rectangle would be described by 4 x 64bit numbers so is 32 bytes of data. Optimising measurements and common cases so that's just 1 byte is worth it when elements may be used hundreds of times in a message. Binary data like a rich graphical document often doesn't compress well so it's not an option to just run a generic compression algorithm over it.
For anyone who's really curious, I do things like storing percentages as integers and if they are decimal percentages (eg: 37.5) as an integer of hundredths of a percent. So a lot of the floating point stuff in graphics ends up as one or two-byte integers.