Why does a bitmap compare not equal to itself?

后端 未结 2 1859
清酒与你
清酒与你 2021-02-09 16:12

This is a bit puzzling here. The following code is part of a little testing application to verify that code changes didn\'t introduce a regression. To make it fast we used

相关标签:
2条回答
  • 2021-02-09 16:37

    Take a look at this, which pictorially illustrates a LockBits buffer - it shows the Rows of Strides and where Padding can appear at the end of the Stride (if it's needed).

    • https://web.archive.org/web/20141229164101/http://bobpowell.net/lockingbits.aspx

    • http://supercomputingblog.com/graphics/using-lockbits-in-gdi/

    A stride is probably aligned to the 32bit (i.e. word) boundary (for efficiency purposes)...and the extra unused space at the end of the stride is to make the next Stride be aligned.

    So that's what's giving you the random behaviour during the comparison...spurious data in the Padding region.

    When you are using Format32bppRgb and Format32bppArgb that's naturally word aligned, so I guess you don't have any extra unused bits on the end, which is why it works.

    0 讨论(0)
  • 2021-02-09 16:50

    Just an educated guess:

    24 bits (3 bytes) is a little bit awkward on 32/64 bit hardware.

    With this format there are bound to be buffers that are flushed out to a multiple of 4 bytes, leaving 1 or more bytes as 'don't care' . They can contain random data and the software doesn't feel obliged to zero them out. This will make memcmp fail.

    0 讨论(0)
提交回复
热议问题