BBitmap::ImportBits misses edge pixels

[Pete]

The ImportBits method misses the rightmost column, and bottommost row, of a source bitmap. ArtPaint currently uses this to import all images into its display (loading a file, pasting a clip, etc.) and the result is always missing the right and bottom sets of pixels. (Originally it did the operation itself explicitly, and that works. For now, I've restored its original scheme.)

For reference, here's the code it uses:

			fLayerData->ImportBits(bitmap, BPoint(B_ORIGIN), BPoint(B_ORIGIN),
				int32(min_c(frame.Width(), sourceRect.Width())),
				int32(min_c(frame.Height(), sourceRect.Height())));

(I guess enclosing B_ORIGIN in a BPoint is superfluous(!), but shouldn't affect things.)

[Pete]

example original 16x16 pixel image

[Pete]

same image after loading and resaving using ImportBits

[Pete]

Dunno why it "Has a Patch set"... Didn't intend to click that (and I don't think I did)! No way to remove the tag.

[pulkomandy]

"has a patch" is a trac bug.

You do need a +1 on rectangle width and height if you want a pixel count. This is a known "feature" of the BeAPI. See ​https://www.haiku-os.org/legacy-docs/bebook/TheInterfaceKit_The_Coordinate_Space.html for details about this.

[Pete]

Urk... I should have remembered that! (Though actually not -- that I can see -- detailed in the Coordinate Space section, only in the preamble to BRect, and implicit in the Width()/Height() descriptions themselves.)

However, I think the parameters in the Bitmap.h header are misleading:

	status_t	ImportBits(const BBitmap* bitmap, BPoint from,
				BPoint to, int32 width, int32 height);

Using "width" and "height" obviously fooled both Julun (the original author) and me in the same way! Maybe "pixelwidth" and "pixelheight"?