Hi Jinoh,
On 10/12/21 8:31 PM, Jinoh Kang wrote:
I performed a test going roughly as follows on Windows 10, build 2108:
- rect = {0, 0, 128, 128};
- hdc = CreateEnhMetaFileW(NULL, NULL, &rect, NULL); // NOTE current session on truecolor desktop
- StretchDIBits(hdc, 0, 0, 32, 32, 0, 0, 32, 32, data, bmi, DIB_RGB_COLORS, SRCCOPY);
The results are as follows:
- bmiHeader.biCompression:
- BI_RGB and BI_BITFIELD: calculates cbBitsSrc based on width/height/depth; ignores bmiHeader.biSizeImage.
- BI_RLE4 and BI_RLE8: cbBitsSrc := bmiHeader.biSizeImage. Fails if bmiHeader.biSizeImage is zero.
- BI_JPEG and BI_PNG: (unable to test -- fails on my system; perhaps incorrect DC settings?)
- bmiHeader.biSizeImage:
- Preserved as-is in resulting EMF, however large or small.
- bmiHeader.biClrUsed and bmiHeader.biClrImportant:
- Preserved as-is in resulting EMF, however large or small.
- Invalid values seem to be also accepted.
- Works also on BI_RGB (no checks are done?)
- Usage of BITMAPCOREINFO instead of BITMAPINFO (size == 12):
- Normalized to BITMAPINFOHEADER (size == 40).
These behaviours closely resemble bitmapinfoheader_from_user_bitmapinfo_sans_ in-line mutation of biSizeImage. Perhaps we can write the calculated size to a separate pass-by-ref variable, and change the original usage as follows:
-bitmapinfoheader_from_user_bitmapinfo(&dst->bmiHeader, &info->bmiHeader); +bitmapinfoheader_from_user_bitmapinfo(&dst->bmiHeader, &info->bmiHeader, &dst->bmiHeader.biSizeImage);Alternatively, we should factor it out into a separate function.
Thanks for testing it. The problem with using a function like above is that it depends on the order values of &dst->bmiHeader and &dst->bmiHeader.biSizeImage are set in bitmapinfoheader_from_user_bitmapinfo. In this case I'd say that skipping size calculation in the helper that sanitizes the header and doing that in a separate helper seems better.
Thanks,
Jacek