Bug: 140715166
Test: I56dc6e9865c2701746c95ea584bcc70fe4d62a6c
AnimatedImageDrawable, when created from a ByteBuffer, needs to get a
pointer to the JNI interface in order to read the ByteBuffer (or
byte[]). But the AnimatedImageThread is not attached to the JVM. Attach
it as necessary.
Change-Id: I51b69b5b70f8c5865d5e5ed065e42267fa556202
Merged-In: I51b69b5b70f8c5865d5e5ed065e42267fa556202
(cherry picked from commit a7ec12f7ef)
Changes to android_opengl_* are generated by editing glgen stubs and
re-running gen script.
Bug: 124338141
Test: atest CtsGraphicsTestCases
(cherry picked from commit 61783592df)
Change-Id: I179f90177c8b1b50a923baecef3b5071a9a25ccf
Merged-In: I715123e66f4ace1d6a11a42c8eafc1d02995e88b
Test: CtsGraphicsTestCases, CtsUiRenderingTestCases,
CtsRenderscriptTestCases
This is significantly faster than passing the Java object down and then
calling a JNI method to retrieve the pointer. See
https://buganizer.corp.google.com/issues/16656908#comment19
In some cases this changes what used to be native crashes (due to
android::BitmapWrapper:assertValid's LOG_ALWAYS_FATAL_IF) into
NullPointerExceptions (if a caller used a null Bitmap).
In addition:
- Remove unnecessary JNIEnv param from toBitmap(jlong)
- Change instances of toBitmap(JNIEnv*, jobject) to the above
- Replace calls to GraphicsJNI::getSkBitmap() to inline calls to
toBitmap/getSkBitmap
- make Canvas#nInitRaster @FastNative (FIXME: Could these be
@CriticalNative?)
Change-Id: I6194097be1b6e6952eba70e1e7052a5a250eed93
Test: I7eb02bc2389aadc10ee0b65993bb7e2dab27a129
Also remove gBitmap_getAllocationByteCountMethodID. These called into
Java, which then called back into native. Instead, call the native method
directly. The only extra wrinkle is that the Java method returns 0
if (mRecycled). But we would never reach that return value, since if
it was recycled, we would have crashed in native Bitmap::assertValid.
Instead, throw an IllegalArgumentException when attempting to reuse
it.
This avoids the overhead of two JNI calls, which tend to be slow.
Change-Id: I29e8d2428036252cfad532b1351e3a3d33817b43
Bug: 127580253
Test: CtsGraphicsTestCases
Perf: systrace
Follow on to I0b42c17159b290868a6bed7b90da096995504c4d, which did this
for other classes. I expect this to be more efficient due to passing
fewer JNI parameters, which appears to be the case based on the systrace
data for setColor(@ColorLong):
Duration:
(w/o this change) (w/ this change)
avg: 0.010 ms 0.005 ms
max: 9.130 ms 0.239 ms
min: 0.002 ms 0.002 ms
std: 0.052 ms 0.004 ms
The average is twice as fast, the max is significantly shorter, and the
standard deviation is much smaller as well.
Change-Id: I241824bf2a934746df93da1063b14f3080486cb5
Bug: 121304803
Test: Infeasible
Previously, the NativeAllocationRegistry needed to report how much
native memory was being held onto by the Java class in order to get a
more accurate count of how much memory was in use. But recent changes
allow the system to have an even more accurate view of the native memory
with mallinfo(). Further, the AOSP change
Idccb8b50d26c8c3e93cc34040d784f74dfcdbf51 introduces new APIs that allow
distinguishing between large native malloc allocations, which should
cause more frequent mallinfo() checks, and whose sizes need be available
to ahat etc, and smaller native malloc allocations.
Bitmap and AnimatedImageDrawable use the version for large native malloc
allocations. The rest pass an implied size of 0. Note that many of the
old Registries used somewhat arbitrary sizes, reinforcing the fact that
the new way of keeping track of this is better.
Add Bitmap::pixelStorageType to differentiate between types of memory
that should be accounted for by the Registry.
Update Bitmap::getAllocationByteCount to report the actual size of
ashmem allocation.
Fix a typo in LineBreaker.java, discovered while looking to find
existing callers of Bitmap's constructor.
Change-Id: I57c407258450aeaf08b47df32432466639d9faed
Bug: 127580253
Test: CtsGraphicsTestCases
Perf: systrace
Restored with a partial revert of "Add Paint#get(ShadowLayer)ColorLong"
(commit 6ee411010e).
The original CL combined the @ColorInt and @ColorLong version for
simplicity, but required doing extra work for the @ColorInt version.
Separating them back out speeds it up at the cost of more code.
Using systrace I see the following stats:
Duration:
(w/o this change) (w/ this change)
avg: 0.020 ms 0.001 ms
max: 9.141 ms 0.072 ms
min: 0.005 ms 0.001 ms
std: 0.074 ms 0.001 ms
This change shows a significant speed improvement. It does not do the
same for setShadowLayer, which is likely used less frequently.
Change-Id: I9021864fcad7d0149b93674f09339f805c272994
Bug: 112551574
Test: make
This reverts commit 023c0fc006.
This was a speculative fix for issue 112551574. Some further digging
revealed that the crash was only occurring in O, b/c it had been fixed
(tracked in issue 63044157). This "fix" and logging are not necessary.
Change-Id: I3a25597d1a38c4acab34fef936283e9a57bae826
This is from API council feedback.
Bug: 124794899
Test: atest CtsTextTestCases
Test: atest CtsGraphicsTestCases
Change-Id: Ifa95f87067239cca9c0791bf079045e4f645c3ad
The hyphen edit is packed into 8bit integer in native library, but this
should not be exposed to public API as API council suggested.
This CL includes:
- Removing packing structure from HyphenEdit and move constants from
Hyphenator to Paint.
- Replace LineBreaker's getLineHyphenEdit with two separate start/end
function.
- Replace Paint's getHyphenEdit with two separate start/end function.
- StaticLayout still relies on this packing mechanism but no longer need
to be the same packing structure as in Minikin.
Bug: 124794844
Test: atest CtsGraphicsTestCases
Test: atest CtsTextTestCases
Change-Id: I8206061f554cf6e119b2b565162f54317eac630a
Bug: 123301872
Bug: 117601185
Test: Manual (Ie18811ba29a1db163aca08472b04ae185e9344f0)
Test: CTS (Ie4b0a232effc67ab7a7fc6070302c722177cadfa)
Test: Infeasible (verify desired ColorSpace is used)
When calling setTargetColorSpace on an ImageDecoder for an animated
image, pass this to the AnimatedImageDrawable. Also respect an EXTENDED
ColorSpace as a cue to decode to RGBA_F16, as with Bitmaps.
Call ImageDecoder#checkState for AnimatedImageDrawables, as with
Bitmaps.
Change-Id: I5f6e11ee14ce4477bfedf2d1fdde8e15ed5f24d5
Bug: 117601185
Test: I5e5bc6b73d5d27ae30f00507d59896008d4cf364
ImageDecoder does not have a way to request decoding to F16 on 8 bit
images, but it does have a way to request an EXTENDED ColorSpace. Treat
that as a request to use a higher bit depth. This matches how we match
EXTENDED to F16 in other cases (createBitmap, Bitmap#copy, etc).
Change-Id: I3d31b13b56bb57a23b47ffcb2eaba11c53e0b8d9
Bug: 123377741
Bug: 120870651
Bug: 121001670
Bug: 123374456
Bug: 124052364
Test: I90adb511c8fdefe016028da4fd53b079d8367bf6
RGBA_F16 is no longer restricted to particular ColorSpaces. (Previously,
it was LINEAR_EXTENDED_SRGB when decoded, and EXTENDED_SRGB when
created.) Instead, F16 is now EXTENDED if there is an EXTENDED variant,
but is otherwise not special. It defaults to SRGB (but EXTENDED), but
can be created or decoded to other ColorSpaces.
Likewise, smaller Configs use the non-EXTENDED variant, when the
EXTENDED variant was requested.
ALPHA_8 always has a null ColorSpace.
Add TransferParameters to EXTENDED_SRGB. This seems to be a relic from a
time before Skia treated SkColorSpaces as non-bounded. Make it have the
same parameters as SRGB, so that it can be used in native code. e.g. now
we can draw to/from it.
Fix a bug getting the ColorSpace for gray image. ImageDecoder's info
previously reported that a gray image's ColorSpace is null. (Though it
correctly decoded it with the proper ColorSpace.)
Allow setColorSpace to request SRGB on an EXTENDED_SRGB F16 Bitmap. (It
has no visible effect.)
Do *not* allow setting a ColorSpace on an ALPHA_8 Bitmap (throw an
Exception). Other attempts to create a Bitmap with ALPHA_8 and a
non-null ColorSpace silently use null, for backwards compatibility.
Copying *from* an ALPHA_8 to another Config returns a Bitmap with SRGB.
Change-Id: Ied0426f6deff354df5998691703a18ddd33ccd3d
Test: CtsGraphicsTestCases
When the comment was written, "the default" referred to
GraphicsJNI::colorSpaceForType, which was either SRGB or null, depending
on a build flag. In If7b1c00ad889446658f98e9ad644869e2eeabcdb, we
changed it to "decodeInfo.refColorSpace", but since bitmapInfo was just
assigned decodeInfo, it already has the same SkColorSpace, so this does
nothing. Remove the code and the comment.
Change-Id: Ib661621e30a6432707bb6894ca5334fba8eca81e
Bug: 123301974
Test: Infeasible
If a Bitmap is going to be decoded to F16 and then converted to
HARDWARE, only decode to F16 if HARDWARE supports it.
Previously, if we discovered after the decode that HARDWARE did not
support F16, we had to copy back to 8888 before the upload.
Change-Id: I3ceb9d053ba134bb96cfb9d638e54ac652e5db29
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
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
