In ImageDecoderHaiku.cpp, the RGBA32Buffer::asNewNativeImage() function doesn't correctly handle the creation of native images. Actually, we used the BBitmap::SetBits() method but the RGBA32 image in the buffer didn't have the same number of bytes per row as the defined constant B_RGBA32 in Haiku. So instead of using this handy method I made a memcpy of the buffer into the BBitmap with the correct number of bytes per row.
Created attachment 38792 [details] Patch v1
Comment on attachment 38792 [details] Patch v1 The ChangeLog really needs a clearer description of why you're doing this. The code might benefit from similar comments. I would probably have pre-computed the source and dest into nicely named locals first: memcpy(static_cast<uint8*>(bmp->Bits()) + y * bmp->BytesPerRow(), 42 reinterpret_cast<const uint8*>(m_bytes.data()) + y * bytesPerRow, minBytesPerRow); r- for an unclear ChangeLog. How is the B_RGBA32 storage different from WebCore's? Should we be using some sort of COMPILE_ASSERTs here to verify the current assumptions?
(In reply to comment #2) > r- for an unclear ChangeLog. > > How is the B_RGBA32 storage different from WebCore's? Should we be using some > sort of COMPILE_ASSERTs here to verify the current assumptions? Actually, the B_RGBA32 storage has a different bytes per row value. I know this can be changed when creating a BBitmap, but unfortunately it only accepts a value greater than the one specficied by the storage (B_RGBA32 in this case). And that's not the case for WebCore's. This results in images that appear as follows (if using BBitmap::Setbits()): http://picasaweb.google.com/lh/photo/Ixx-Io8UeGY--fxhTROE1A
This bug is outdated and can be closed. A more complete patch which fixes the issue has been landed. The problem the patch above tried to fix rooted in the wrong rect conversion. Otherwise BBitmap::BytesPerRow() is 32 bit aligned, i.e. there is no difference to the WebCore internal image data storage in this regard.
Closing per comment 4.