Embarrassing assumptions
Shared by AndyDent-Touchgram · 33d ago · 5 comments

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.

alessandrosolbiati · 33d ago

dude! that's crazy ahah you are a real hacker man

andrew-miit.co · 33d ago

This kind of stuff would be great for other devs to hear.

jerico · 33d ago

Great learning, good on ya for sharing! :)

kendsouza · 33d ago

Animation is not my domain..but I like the nerdy technical details:)
Just the other day I saw this tweet..thought I will share this with u. Monster Mash, an open source animation project.

AndyDent-Touchgram · 33d ago

Thanks, that's a very cool tool.

Technically, the term for having joints that track to make things like walking easy is Inverse Kinematics and it's been built into SpriteKit, the engine behind Touchgram, for about 4 years. https://developer.apple.com/documentation/spritekit/working_with_inverse_kinematics

I've spent enough months making our core model encode and decode the basics needed for the next year or so of Touchgram so will leave this as an exercise for sometime 2022.

But, thanks to you, I now have a cool paper to read on how their UI works.

Picking objects in 3D space is very hard to get right - I've used 3D CAD for house design over the years and worked on a 3D CAD product for minesites. About 20 years ago I was on a team that built an Identikit for Cars that let police officers in the field apply markings and decals to 3D car models, to create an accurate representation of a suspect's car. I vaguely remember that having major UI simplifications.

The paper linked from the tweet is worth a read, with great insights on how to focus on user behaviour to simplify a design: most forms of artistic expression have a casual mode ... many 3D models, particularly those of organic forms, can be described by an ordered set of overlapping 2D regions.

I teach kung fu on the weekends and was just reminded how often complex movements in 3D space are easiest to learn when you break things down to planes that are then separately moved. You're circling your hand on this plane then you turn your body 45 degrees and step past that point.