What's the reason both Image and Bitmap classes don't implement a custom equality/hashcode logic?

Question

From MSDN documentation, it seems as both GetHashCode() and Equals() haven't been overriden in Bitmap. Neither have them been overriden in Image. So both classes are using the Object's version of them just compares references. I wasn't too convinced so I decided to fire up Reflector to check it out. It seems MSDN is correct in that matter.

So, is there any special reason why MS guys wouldn't implement "comparison logic", at least for the Bitmap class? I find it is kinda acceptable for Image, as it is an abstract class, but not so much for the Bitmap class. I can see in a lot of situations calculating the hash code can be an expensive operation, but it'd be alright if it used some kind of caching.

When wanting to compare 2 bitmaps, will I have to resort to having to run all over the picture comparing each one of its pixels?

Thanks

Answer 1

Let's flip that question around; is there any special reason why they would implement such a thing?

For one thing, it would be very, very expensive to compute the hash, making it all but useless for hash tables and the like. Just try to imagine doing this on a whole slew of 1920x1200 bitmaps; doing it even one time for each bitmap would slow the program to a crawl. I would expect that 9 times out of 10, when somebody has to compare two bitmaps, they want reference equality, not pixel-by-pixel value equality.

And what you refer to in your question isn't lazy evaluation, it's caching. Caching is a non-trivial feature to implement, and every feature starts at minus 100 points.

With all that in mind, my answer to this would be that the methods aren't overridden because the overridden versions wouldn't be particularly useful to many people, relative to the cost of implementing and maintaining such a feature. If you really want pixel-by-pixel comparisons (or checksums, or similar things), then you can always implement them yourself in 10 lines or so.

Answer 2

Equality semantics in the .net framework are pretty well standardized; it would seem to violate the principal of least surprise if references to bitmaps tested for equality in the way you expected.

Answer 3

When the built-in bitmap comparison that MS did not implement is run, it would need to resort to comparing each of the pixels. Sure, MS would probably do a raw memory comparison (perhaps in an unsafe block), but you can do the same thing if you want. Regardless, comparing two bitmaps will always be expensive. And you cannot rely on hashes both because calculating a hash is generally going to be as expensive as a comparison...and you'll be forced to rely on a raw pixel comparison to verify equality when the hashes match, since hashes only prove inequality.

I have not provided a demonstration that Equals and GetHashCode are useless in a Bitmap. However, I have provided a demonstration that they are often going to offer surprising, unexpected costs to users and will not be a good solution in ordinary use cases. Adding extra functionality to a type like this is expensive, and I'm not convinced it would have much benefit. And it would often cost a lot. This is the kind of thing you should implement yourself, or use a 3rd party library.