You can't conclude that the "copying" is all the way down just because you get different addresses back. It depends on the implementation.
I'd agree, except I'm checking all the way down. BitmapData is a type char*, or void*, and diddling here changes individual pixels. Either way, that is the base bit data, with no further pointers or metadata. The program shows that the actual data is in actually different locations. So in this case, there's no way, except some serious voodoo.
I suppose you can do akin to how forked processes handle copied memory. That is, copy on write. But that'd require this single thread to have two different memory addresses to point to the exact same location in a page. It's possible, but downright scary. Not only that, but were that the case, I'd expect to see the same offsets from page boundaries, which wasn't the case.
The other notable hint is that the convention seems to be that immutable objects retain instead of copy, but mutable objects copy to an immutable version. This is how it is with NSString and NSArray. But NSImage isn't immutable. The base class is mutable in its declaration.
It is possible to make an exception by implementing your own NSImageRep subclass that copies on write. But I'm concerned with the default behavior. And accessing an Apple-supplied image from a singleton instance of an Apple-supplied class, where the image source should be a read-only ICNS file, is the closest example I can think of a default immutable NSImage.
Hmm. The one thing I didn't check is the image caching. That could still be uncopied, as it should only be updated when the image changes. But that's relatively short-lived data, anyways. The other thing would be vector graphics. The other possible exception is that -bitmapData forces the copy... I'll have to build up a few tests to check this out, but the Right thing to do, implementationwise, is to copy on -copy, especially when so much underbelly can be exposed.
I'm still rather confident that bitmaps can be treated as copied even to the pixel level, at least in terms of CPU load.
by Blain — Sep 29
I'd agree, except I'm checking all the way down. BitmapData is a type char*, or void*, and diddling here changes individual pixels. Either way, that is the base bit data, with no further pointers or metadata. The program shows that the actual data is in actually different locations. So in this case, there's no way, except some serious voodoo.
I suppose you can do akin to how forked processes handle copied memory. That is, copy on write. But that'd require this single thread to have two different memory addresses to point to the exact same location in a page. It's possible, but downright scary. Not only that, but were that the case, I'd expect to see the same offsets from page boundaries, which wasn't the case.
The other notable hint is that the convention seems to be that immutable objects retain instead of copy, but mutable objects copy to an immutable version. This is how it is with NSString and NSArray. But NSImage isn't immutable. The base class is mutable in its declaration.
It is possible to make an exception by implementing your own NSImageRep subclass that copies on write. But I'm concerned with the default behavior. And accessing an Apple-supplied image from a singleton instance of an Apple-supplied class, where the image source should be a read-only ICNS file, is the closest example I can think of a default immutable NSImage.
Hmm. The one thing I didn't check is the image caching. That could still be uncopied, as it should only be updated when the image changes. But that's relatively short-lived data, anyways. The other thing would be vector graphics. The other possible exception is that -bitmapData forces the copy... I'll have to build up a few tests to check this out, but the Right thing to do, implementationwise, is to copy on -copy, especially when so much underbelly can be exposed.
I'm still rather confident that bitmaps can be treated as copied even to the pixel level, at least in terms of CPU load.