Bug: 120904891
Test: I162451ebf807f3a8a44679e5c10406468c922500
- Add Bitmap#eraseColor(@ColorLong). This allows erasing in ColorSpaces
besides SRGB. New API is hidden pending API-council approval. It is
@TestApi so it can be used by the new tests.
- Rewrite Bitmap#erase(@ColorInt)'s internals. The ColorInt should be
treated as an SRGB color. The old code (deep in SkPixmap::erase)
treated the color as being in the SkColorSpace of the SkBitmap.
- Update getNativeColorSpace to return immediately when it throws.
Existing callers should never throw anyway, since they do their own
checks (and throws) in Java before reaching this method. But relying
on this method to properly return simplifies the new callers.
Change-Id: I1b736934ce1b8294c827bb61c2a363207569da4f
Bug: None
Test: I solemnly swear I tested this conflict resolution.
Merged-In: I7fc1162d2c63df8751a4660607e8ce72070efed8
Change-Id: I0e5a5d8fda273644e8c592ce7d059e508870085e
For packages:
android.graphics
android.graphics.drawable
android.graphics.drawable.shapes
android.graphics.fonts
android.graphics.pdf
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Merged-In: I7fc1162d2c63df8751a4660607e8ce72070efed8
Change-Id: I5d7739d2d1fc7bb12ee059bcc2a9ac9017ca35fb
For packages:
android.graphics
android.graphics.drawable
android.graphics.drawable.shapes
android.graphics.fonts
android.graphics.pdf
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I7fc1162d2c63df8751a4660607e8ce72070efed8
Picture#draw() will silently due an #endRecording() if it
wasn't called. Bitmap.createBitmap doesn't do this until
after it's too late.
So do an up-front #endRecording() to ensure state is
good to go
Bug: 80539264
Test: HardwareBitmapTests#testReadbackThroughPictureNoEndRecording
Change-Id: Ic66c41462e88880b73c5093d7541c4ce3d71adeb
Test: Build, CTS
mNativePtr can never be 0 (it is final, and the constructor prevents
setting it to 0), so do not check for it. nativeRecycle only ever
returns true, so make it return void.
Change-Id: Ib94c0304ca7303d6899f085e64be7c051908d173
flag
Updated Bitmap java and native implementation to redirect queries of
mutability to the native implementation provided by Skia. Updated
documentation of Bitmap.createBitmap method to accurately describe
mutability of the Bitmap result based on various inputs.
Removed flag from Bitmap class in favor of querying jni API directly.
Updated Bitmap constructor to no longer utilize mutable parameter
provided by jni call. Created hidden setImmutable method that invokes
corresponding native method to flip the Bitmap's mutability flag.
Fixes: 65560449
Test: Re-ran CTS tests and updated Bitmap tests to verify mutability of
all creation methods
Change-Id: I1b0b9de2fc15369b4e3f83512b866915387ac926
This CL documents the byte order for 585, 8888, and fp16 buffers.
Test: documenting existing behavior
Bug: 71518511
Change-Id: I128344db318eb4597b6eb00f0ae317e369145152
Bug: 74408046
Test: Ic6acdc4a1a16840ec6ad9b13b4926c643d0f81ae
Skia incorrectly sets the gamma for LINEAR_EXTENDED_SRGB to 0 as a
misguided optimization attempt. As a result, a HARDWARE Bitmap which
natively has this color space does not match it properly. (Note that we
already catch an F16 Bitmap, above.) Add a workaround in
Bitmap.getColorSpace() to check for the color space explicitly.
Change-Id: Id595e365d1c8d572cfcea214d230a8ce1decdc01
Bug: 34881007
Test: bit CtsGraphicsTestCases:*
Test: bit CtsUiRenderingTestCases:.testclasses.HardwareBitmapTests
Change-Id: Ic751c356682ea3db17a1b031ec46106a1a2ab918
This regression is a fallout from the recent API council feedback
fallout. The default color space used to be always set to null but
it's now the named SRGB instance. This change passes null to native
when the specified color space is known to be sRGB.
Bug: 37496760
Test: runtest managed-provisioning
Change-Id: Ie933c84e429a682a58ee253b57b77bd61b88ee5e
Implement missing color management pieces for bitmaps:
- Bitmap.createBitmap(Bitmap src, ...) now creates a bitmap
in the same color space as the source bitmap
- Bitmap.createScaledBitmap() now creates a bitmap in the
same color space as the source bitmap
- Bitmap.createBitmap(..., ColorSpace colorSpace) to create
bitmaps in a specific color space
- Fix copy from A8 to F16
- Copying bitmaps in F16 or with a color space does not work,
it's currently a limitation in Skia
Bug: 36905374
Test: BitmapColorSpaceTest
Change-Id: I0092fe4432511db50daa3a9393389a9db05e0c2a
This change also resets the cached color space field in Bitmap.java
when reconfigure() is called or when a bitmap is reused by the
bitmap factory.
Bug: 32072280
Test: CtsGraphicsTestCases.BitmapColorSpaceTest
Change-Id: I232b729b7a29e65bfff21dc749570c3c80adf855
This is the first step toward interpreting color spaces at render time.
Bug: 32984164
Test: BitmapColorSpaceTest in CtsGraphicsTestCases
Change-Id: I0164a18f1ed74a745874fe5229168042afe27a04
This configuration uses 64 bits per pixel. Heach component is stored as a
half precision float value (16 bits). Half floats can be decoded/encoded
using android.util.Half.
RGBA_F16 bitmaps are used to decode wide-gamut images stored in 16 bit
formats (PNG 16 bit for instance). aapt is currently not aware of PNG
16 bits so such files must be placed in raw/ resource directories.
This first pass provides only partial drawing support with hardware
acceleration. RGBA_F16 bitmaps are stored in linear space and need
to be encoded to gamma space with the appropriate OETF to be rendered
properly on Android's current surfaces. They are however suitable for
linear blending. Full rendering support will be provided in a future
CL (BitmapShaders might be a bit tricky to handle properly during
shader generation).
Bug: 32984164
Test: bit CtsGraphicsTestCases:android.graphics.cts.BitmapRGBAF16Test
Change-Id: I328e6b567441a1b9d152a3e7be944a2cf63193bd
All draw* calls in Canvas are regular JNI
All draw* calls in DisplayListCanvas are FastNative
Unifies Canvas JNI on nMethodName naming
CanvasPerf results before:
INSTRUMENTATION_STATUS: basicViewGroupDraw_min=12492
INSTRUMENTATION_STATUS: recordSimpleBitmapView_min=13912
and after:
INSTRUMENTATION_STATUS: basicViewGroupDraw_min=11945
INSTRUMENTATION_STATUS: recordSimpleBitmapView_min=13318
Test: refactor, makes & boots
Change-Id: I06000df1d125e17d60c6498865be7a7638a4a13e
