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