macOS Why is my NSColor Archived as NSData so big?

[GorillaPaws]

I'm refreshing my Cocoa knowledge by working through Hillegass's 4th edition of the famous "Cocoa Programming for Mac OS X." I'm at the end of Chapter 13 where he describes how you can view your User Defaults via the terminal using the command:

defaults read com.bignerdranch.RaiseMan

The BNREmptyDocsFlag is 1 which is expected, but the BNRTableBGColor is a significant block of data:

62706c69 73743030 d4010203 04050615 16582476 65727369 6f6e5824 6f626a65 63747359 24617263 68697665 72542474 6f701200 0186a0a3 07080f55 246e756c 6cd3090a 0b0c0d0e 5624636c 6173735c 4e53436f 6c6f7253 70616365 554e5352 47428002 10014f10 1c302e34 38363230 36313232 3320302e 36393834 32333630 35382031 00d21011 12135a24 636c6173 736e616d 65582463 6c617373 6573574e 53436f6c 6f72a212 14584e53 4f626a65 63745f10 0f4e534b 65796564 41726368 69766572 d1171854 726f6f74 80010811 1a232d32 373b4148 4f5c6264 66858a95 9ea6a9b2 c4c7cc00 00000000 00010100 00000000 00001900 00000000 00000000 00000000 0000ce

I'm wondering why an NSColor (which is just a red, green, blue, alpha value right?) is so big? Is this bloat related to the way NSData boxes up NSColor objects? or am I missing something?

 

[MacRohde]

When archiving an object as a structured data stream some bookkeeping info is needed: what object is this, what is its private data. In the case of a color, only r, g, and b isn't enough. What about alpha? And which color space is this color? RGB, CMYK? I think the color space stuff could take up some space.

 

[dylanryan]

Converting the first bit to ascii, it looks like a binary plist, so I made a binary file with those contents, and it is indeed a wellformed binary plist. Saving that out as a text plist, I get:

{
	"$version" = 100000;
	"$objects" = (
		"$null",
		{
			NSRGB = <302e3438 36323036 31323233 20302e36 39383432 33363035 38203100>;
			NSColorSpace = 1;
		},
		{
			"$classname" = NSColor;
			"$classes" = (
				NSColor,
				NSObject,
			);
		},
	);
	"$archiver" = NSKeyedArchiver;
	"$top" = {};
}

and the stuff inside the NSRGB, when converted out of hex, turns out to be:

"0.4862061223 0.6984236058 1"

So, it looks like it saves... the hex representation of a binary plist that contains the hex representation of the ascii characters representation of a floating-point-number expressed in base 10. Which seems like a few needless encoding jumps to be sure, but I guess it works and probably made sense to someone at some point.

EDIT: Not quite as bad as I thought, looking closer, I do see the hex data in the NSRGB in the original hex, too, so they aren't encoding hex into ascii and then re-hexing that, at least!

 

[GorillaPaws]

Thanks for the quick and very thorough replies!