Skia's sk_sp class is moving from operator pointer to field to
explicit operator bool. As a result a few uses need to be updated.
Test: refactoring CL. Existing unit tests still pass.
Change-Id: I97ca0647c7c490554da7dd626c99b3447d7cbc84
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
Bug: 78866720
Test: Manual + systrace; existing CTS
Previously, we set hasAnimations to true when the AnimatedImageDrawable,
so that we would get a call to redraw. But if the image does not need to
show its next frame yet, the redraw was unnecessary.
Instead, add a new field to TreeInfo::Out, representing the delay time
until the image will need to be redrawn - i.e. when the duration of the
current frame has passed. Each call to prepareTree will post at most one
message to redraw, in time for the earliest animated image to be
redrawn. Post the message for one rendered frame ahead of time, so that
when it is time to show the next frame, the image has already gotten the
message to update.
On a screen with a single animated image, this drops the number of calls
to dispatchFrameCallbacks to as infrequent as possible. It is called
only when we need to draw a new frame of the image. On a screen with
multiple animated images, the calls may be redundant, but they will not
be more frequent than they would be without this change.
Switch to nsecs_t and systemTime internally, matching the rest of HWUI.
Remove mDidDraw and related. Its purpose was to prevent advancing the
animation while the image is not being drawn. But it isn't really
necessary. If it's not drawn, onDraw is not called, which is where we
trigger decoding. And onDraw already has a defense against getting too
far ahead - if its timer indicates that it should skip a frame or show
it very briefly, it will back up its timer. More importantly, mDidDraw
caused a bug, when combined with less frequent redraws. If the display
list containing the drawable doesn't need to be redrawn for other
reasons, the drawable's timer never advanced, so its animation stopped.
Fix software drawing. Compute the milliseconds in the future to draw the
next frame, and add that to SystemClock.uptimeMillis() to compute the
time to pass to scheduleSelf.
Change-Id: I13aab49922fa300f73b327be25561d7120c09ec4
Bug: 78866720
Test: Manual
If the input stream is seekable, SkGifCodec will read from it directly.
If not, it has to copy (parts of) the input in order re-decode when it
loops. Directly use the seekable SkFILEStream so that SkGifCodec skips
the copy, saving memory proportional to the size of the file.
Depends on a change in upstream Skia which allows SkFILEStream to treat
the initial offset as the beginning of the file:
https://skia-review.googlesource.com/c/skia/+/126511
Change-Id: Iefb58785157ba684ad3603778175b3dba97567b2
Bug: 78866720
Test: Manual
It already supports rewinding, and the underlying Asset supports
seeking. Allow it to be seeked so that SkGifCodec can read directly from
it rather than copying data it needs for internal use.
Change-Id: I0765dcf4a507724878a5a700a770d35802c4b7be
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
Bug: 76448902
Bug: 70889348
Test: Manual + CtsThemeHostTestCases
(Ica5e7e81848c3880accee922ee6f1cc9e26262ca)
Scaling a nine-patch requires scaling its divs. When the scale factor is
not an integer, we have to round. This gets out of sync with the way the
decoder scaled the image, resulting in stretching or keeping fixed the
wrong portions of the image. Making this worse, when we scale down, we
end up with divs colliding with each other, and we have to arbitrarily
adjust them further so they do not collide.
NinePatchDrawable and the drawing code already know how to handle
drawing from the originally-sized image and do a better job stretching
appropriately, so allow them to do their job.
We already do something similar for Bitmaps created by ImageDecoder on
apps targeting P and above - instead of scaling them up, we allow the
BitmapDrawable's scaling code to handle density differences. We
preserved the old behavior (scale up) on apps targeting pre-P because
those apps may rely on the size of the Bitmap contained in a
BitmapDrawable without accounting for its density (see Bug: 74061412).
But that is not an issue for NinePatchDrawables, which do not allow
peeking at their internal Bitmaps.
Rewrite ImageDecoder.computeDensity. There is no need for it to be
static, since it takes an ImageDecoder as a parameter and reads its
fields, including the new field mIsNinePatch. Set mIsNinePatch in the
constructor to avoid another down call into native. Split up the
conditions that result in returning srcDensity without calling
setTargetSize for clarity.
Remove ImageDecoder constructor from the graylist. It was accidentally
added due to the fact that it is called transitively from public APIs.
Change-Id: I3c5ddd67f3352c991515f30ce1c477c9a608833f
Bug: 76448408
Test: I851173b771668f0e6712bebfe06bfb8559801199
Add ImageInfo.getColorSpace() for retrieving the default ColorSpace.
This matches BitmapFactory.Options.outColorSpace.
Add ImageDecoder.setTargetColorSpace() for choosing a new ColorSpace.
This matches BitmapFactory.Options.inPreferredColorSpace.
Rename setSampleSize to setTargetSampleSize to match setTargetSize and
setTargetColorSpace.
Change-Id: If2f4e755dfc163f754849f896de24659198973db
Bug: 73788969
Test: I501e8b76aacd785cb994165ab01dc1b39fea3a1c
Move them into ImageDecoder.DecodeException, which is where they are
actually used. This also provides some more context, so that the prefix
"ERROR_" is no longer necessary, fixing the redundancy/awkwardness in
ERROR_SOURCE_ERROR. Further rename that to SOURCE_MALFORMED_DATA, which
is more descriptive, and does not imply a Java Error.
Change-Id: Ied17ad343650f9c33d9a35b0f9d00ccc22264bd6
Bug: 73788969
Test: If9e27a6ce2604128a619bc4843d62711f94b4d87
Add a new Exception subclass that contains information about the type of
error, and the original Exception, if any. Remove the old
IncompleteException class. If the decode creates a partial image, pass
the information up to Java, where we create the new Exception and pass
it to the callback and/or throw it. Rewrite nDecodeBitmap to always take
the ImageDecoder as a parameter for this callback, and simply use a
boolean to determine whether to call onPostProcess
Check for exceptions in some overlooked cases in native code, and
route to the new type.
Remove FIXME to avoid parsing the whole image. In my limited testing,
it didn't seem to speed anything up, and this should be called in a
background thread anyway. Parsing now also ensures that we've read the
stream when we can have a chance to handle the exception from the right
place.
Remove fixme for b/70626068, which has been marked as WontFix.
Add a TestApi for testing an Exception thrown by an InputStream.
Remove onPartialImage from hiddenapi-light-greylist.txt to fix the build
error this change introduces. onPartialImage was erroneously added to
the list.
Change-Id: I12f69857328e63c993bd669412b06addeb6a74f1
Bug: 73641604
Test: infeasible
Fix nNativeByteSize's return value to be jlong, instead of long.
Add up the bytes used by the SkAnimatedImage and SkPictures and store
them on the AnimatedImageDrawable for registration.
Note that this is an approximation, and it assumes it will be drawn to a
hardware canvas and animated.
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: 70846442
Test: I5110881203c000474116a94a48f2afc9a9b62001
Delay computing decodeColorType until right before we may change it (and
delay reinterpreting the pointer along with it). More interestingly,
defer computing decodeColorSpace until *after* we may have changed the
decodeColorType. Along with a change in Skia, this allows us to match
the color type of inBitmap, as intended.
Change-Id: If0ca4a61d338a13473a96faf900c84010ae46d41
Bug: 73743812
Bug: 71430152
Test: If2c3ee0f32eff77b11ce5a7fe82c02811ed1beb3
This matches how we handle decoding images with a wide gamut. For WebP
and JPEG, we cannot encode with more precision anyway. For PNG, we could
in theory encode to 16 bit linear PNGs. This would be more precise, but
would still throw away information due to normalization. Using 8-bit P3
matches the behavior for the other formats, so it is nice to be
consistent.
Change-Id: I69a44a3eff70e26448a75ecc63ed7604b9c74a95
