Closed errnoh closed 12 years ago
Hmm, this probably causes problems with CopyRGBA as well..
We probably need to at least iterate sy in CopyRGBA from top to bottom.
Though it would just be easier if we could flip the coordinates right way around to begin with
Ah, right. We can change the coordinate in SetDIBitsToDevice with:
YSrc [in] The y-coordinate, in logical units, of the lower-left corner of the image.
Which is currently set to 0, resulting the image to start source coordinates at bottom left instead of top left. Is it ok if I change the win.DIB to use top-down coordinates instead of bottom-up ? Current one can be quite confusing and it would be more similar to image.RGBA.
bottom-up is forced for compressed images, but wde/win is using bi.BmiHeader.BiCompression = w32.BI_RGB, which is uncompressed (makes sense since we're drawing to screen) we can use top-down without problems. Destination is using top-down as well based on the call to SetDIBitsToDevice.
(obviously need to check it works like I think it should first :)
It does seem to work as it should. Changing the height to negative bi.BmiHeader.BiHeight = -height as documented in http://msdn.microsoft.com/en-us/library/aa930622.aspx does result in compatible top-down DIB image.
After this we don't need to change the YSrc at all. Probably good idea to check that CopyRGBA works fine as well. (which it should since PixOffset starts from beginning of Pix)
CopyRGBA starts from right coordinates now as well. This commit should fix the issue in question.
Yeah sorry about this.
Win.DIB starts coordinates from bottom left it seems (w32.BITMAPINFOHEADER can configure that by passing negative BiHeight) and in the new DIB the PixOffset didn't take this into account, resulting in mirrored images when using wde/win. Kinda went under the radar since At(x,y) showed right color in each position.
Changed the PixOffset back to the old one (except 32bit instead of 24bit) and wdetest now shows same image for both xgb and win.