Color space #8
Color space #8
Conversation
| * @param bitmapConfig Currently only {@link Bitmap.Config#ARGB_8888} | ||
| * and {@link Bitmap.Config#RGBA_F16} | ||
| */ | ||
| public native Bitmap getMutableBitmap(Bitmap.Config bitmapConfig) throws IllegalArgumentException; |
There was a problem hiding this comment.
small thing around naming: given non-hardware bitmaps can also be immutable (and there's a lot of reasons to make a non-hardware bitmap immutable), maybe it's better to separate out mutability from the bitmap config, and name this something like getNonHardwareBitmap, getSoftwareBitmap (both of these are terrible, I know!) or even getRAMBitmap and getVRAMBitmap? obviously all these names kind of suck in various ways but separating out mutability does seem nice. totally fine to keep it as is too.
There was a problem hiding this comment.
Because of the way the bitmap is created it is always mutable. In the C code I'm called Bitmap.createBitmap(). The code was modified in this PR to support ColorSpace, so it should be easy to find. If you need an immutable version you can call Bitmap.copy(). I'm not sure I can create an immutable Bitmap because I need to mutate it to copy in the pixels from LibRaw.
FYI: Hardware Bitmaps are technically mutable if the underlying HardwareBuffer is.
There was a problem hiding this comment.
ah good point, any bitmap created by createBitmap is mutable, and can be made immutable. this is great, thanks!
| */ | ||
| @RequiresApi(26) | ||
| @Nullable | ||
| public HardwareBuffer getHardwareBuffer(int format) { |
There was a problem hiding this comment.
this is nice, I love the ability to just get a buffer rather than a bitmap. will make passing it around way easier.
There was a problem hiding this comment.
I thought you said you had a need for this, so I exposed it.
No description provided.