The bitmap.createHardwareBitmap doesn't take a ColorSpace as input, as a result
the returned bitmap is always in SRGB color space. Given that we want to remove
the assumption of SRGB color space, we replace the usage of
createHardwareBitmap with wrapHardwareBuffer which takes an extra argument
ColorSpace. As a result, we will be able to also fix SurfaceControl and various
other places that use screenshot in follow up patches.
BUG: 120904891
Test: CtsUiRenderingTestCases
Change-Id: I57fc0c85d68df43b0e69f9a1ebac00d2ba39554d
Bug: 122844033
Test: Id1809aef84eca0ccc61bafc2476ad52ed78d5f22
Add APIs that mirror the existing creation APIs, but use @ColorLongs
instead of @ColorInts. Note that call-sites that used a null array (but
not a variable "int[]" pointing to a null array) are now ambiguous. It
is unlikely that there are any such call-sites, though, since they would
throw NullPointerException.
Consolidate constructors. Those that take two color endpoints now create
two-member long-arrays and call the more general constructor, saving
lots of code. The additional cost of small arrays is not as much as it
used to be, in the early days of Android, when this class was written.
In *Gradient#copy, there is no longer any need to clone the colors
array, since the mColorLongs was created by the Gradient. Similarly,
there never was any need to clone mPositions, which was always a clone
of the user-supplied array anyway.
Clean up Shader.cpp:
- Throw and return if the pointer is null before dereferencing it.
- Simplify and put together matrix-related code.
Change-Id: Ib71c5e85b2a398959bf687bce33980d3429bcbc3
Bug: 120904891
Test: I61ba938cdbea5154187c3a075c84436f2db81174
getColor returns a Color object in the ColorSpace of the Bitmap.
The underlying SkBitmap may contain values that are outside the
numerical range of the ColorSpace, so clamp them to fit.
Change-Id: I4174b75a83f18d6e165dbd2c724708276e80af21
A previous change added two new public ColorSpace APIs. These APIs are
being used only by ColorDisplayService for specific purposes, so for now
make them hidden.
Bug 116516917
Change-Id: Ib644d356a84d4122173ea4cafbac88bd63b1afcd
The suppression was added to FontsContract by
I7fba3e4d21fc895dfee4300db7d7e3000095ff92 but not in
Resources.getFont.
This CL adds suppression for Resources.getFont too.
Bug: 122262093
Test: locally verified
Change-Id: I15159dadc7e3694be5d90435a7a24cd626086656
The bitmap.create() function that does not take a colorspace does
not enforce that the bitmap is linearly encoded and as such it is
possible for us to end up with FP16 bitmaps that are sRGB encoded.
Given that we want to remove that restriction (see b/120870651)
we update getColorSpace to report the actual colorSpace of the
underlying bitmap. This pulls a thread that causes a chain of
updates to various classes to ensure proper handling of the native
colorspace.
Bug: 120904891
Test: CtsUiRenderingTestCases
Change-Id: I27780aa603138b0e48f9320c2837bc53e22cdf95
Bug: 120904891
Bug: 122844033
Bug: 122514935
Test: CtsGraphicsTestCases
Only convert rgba. ColorSpace should be converted in Java, so we can
just pass the native pointer and handle potential Exceptions before
going into native code.
Requires a change to external/skia [1] to make SkHalfToFloat SK_API.
[1] https://skia-review.googlesource.com/c/skia/+/185140
Change-Id: I0b42c17159b290868a6bed7b90da096995504c4d
Bug: 120904891
Bug: 122844033
Bug: 122514935
Test: CtsGraphicsTestCases
Create an SkColorSpace when creating an android.graphics.ColorSpace.Rgb.
This allows simplifying getNativeColorSpace, so that each time we need
it, we do not need to call back up into Java or reconstruct the
SkColorSpace.
Funnel all ColorSpace.Rgb constructors into one, so we can set a final
mNativePtr in the base constructor. Update TransferParameters to also be
final.
Use the same TransferParameters as SRGB in EXTENDED_SRGB and DISPLAY_P3.
When passing a BitmapFactory.Options to native, call getNativeInstance()
(which may throw an Exception) and pass the result to native.
Move native ColorSpace code into its own file.
Make Paint methods @CriticalNative again, now that they do not need the
JNIEnv.
Remove unused decodeBitmap.
Change-Id: I60adbb060b87ab6f92559f1217bfefc0b9ea72e1
Bug: 120904891
Test: I6de01bd94fade605643af590f8d6909f09a5831e
Store Paint's colors (both the ShadowLayerColor, and the previously
uncached color that is stored in the native SkPaint) as @ColorLongs.
When setting or retrieving the int version, convert. This allows
returning the long value that was manually set, so that we return the
color in the ColorSpace that was requested.
Since the color is already stored in Java, remove nGetAlpha, and return
the alpha from the ColorLong. When setting alpha, update the cached
value, too.
Make setShadowLayer(..., @ColorInt) and setColor(@ColorInt) call the
@ColorLong versions, so they can share single JNI entry points.
Change-Id: Ifc559893dd4db2629c59b6e53f0b2166d43e6049
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
This change adds Display Auto White Balance to ColorDisplayService.
Given panel chromaticity data, a nominal white point, and a desired
correlated color temperature (CCT), this logic generates and applies a
matrix transform to shift the nominal white point to match the desired
CCT.
Bug 116516917
Change-Id: I07e341881a020a130944217fff372003edac0a8c
Test: Ide74c2e98d4aadba8bb0a24d132f161dbe64f4db
Previously, BT709 was believed to be SRGB, resulting in errors when we
tried to convert between them. Make isSrgb test several values passed to
OETF and EOTF to verify that it is very close to SRGB. This results in
BT709 no longer being considered SRGB, fixing the conversion.
Update the documentation to reflect the new behavior.
Now that isSrgb is more restrictive, a gamma of 2.2 is no longer
considered to be SRGB, which requires a change to a CTS test.
Change-Id: I7bf8d5e3af2f91e38ca0b0d5d906713a125dd484
The Jpeg image format must support additional dynamic
depth metadata according to the new standard. Camera
devices supporting non-exclusive depth map streams
along with appropriate Jpeg output will include this
new format by default.
Bug: 109735087
Test: Camera CTS
Change-Id: Id628466323a1ffbbdc7b44a5d15fe8df1cab8743
Test: I1759437bf620868706be0aadce2250ac9194ca7d
The intent is that an index that does not match a Named ColorSpace will
throw an IllegalArgumentException, so make that true for
Named.values().length, which does not correspond to one.
Also, update the Exception message to make it clear that the last index
is exclusive.
Change-Id: I015b7ee6274873cc329653473ead04b08f1cd55f
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: Ia937d8c41512e7f1b6e7f67b9104c1878b5cc3a0
Merged-In: I020a9c09672ebcae64c5357abc4993e07e744687
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: I020a9c09672ebcae64c5357abc4993e07e744687
Implement controlWindowInsetsAnimation
Based on the leashes we have on the client, and the insets the
client has requested, we are able to move the surfaces around
such that the resulting insets will match what the client
requested.
Bug: 118118435
Change-Id: I0616e53455a6544aaf374c1b0eb10e258aced21d
Instead of allocating a separate renderTarget and switching
between them on each draw the new implementation follows the same
pattern that the old HWUI renderer used. The area of the layer is
now copied to a buffer on the GPU, the area is then cleared, rendered
as normal, and finally the texture is redrawn using dst_over blending.
This results in no render target switches and is considerably faster
on some hardware.
Test: CtsGraphicsTestCases, CtsUiRenderingTestCases
Bug: 119222339
Change-Id: I716aac1fc31e4c7a171373d37dee82034c01cf18
Before this change, creating a DrawableWrapper (through a custom class
that extends it) using the public constructor will not set the drawable
callback properly and DrawableWrapper will not update when the
underlying Drawable is invalidated.
Test: CTS test added
Bug: 120835632
Change-Id: I3545db76e032c0bd074846e0fa64c5cf01e2941c
