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
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
Works around a source of jank when drag resizing in split
screen mode: instead of immediately resizing the (potentially
numerous) invisible secondary stacks, we defer that until
the user lets go of the handle.
Change-Id: I3b9faa83005fa86185d4e51b2849e3a826b7f6a9
Fixes: 78214347
Test: Open a gazillion (resizeable) tasks. Enter split screen. Drag handle, verify there is no jank
Test: atest RectTest
StackView currently expands the clip of the view which is a prohibited
operation in API Level 28. This CL currently allows this specialized
use case to work in this situation until we can update StackView
to not clip to its bounds and then just intersect with this clip
provided by its parent.
Test: CtsWidgetTestCases
Bug: 77642155
Change-Id: Icc003ad3946bb226368ec2030d4707753f4f55e9
Bug: 73088142
Test: Test app at https://buganizer.corp.google.com/issues/73088142#comment6
Test: GridWidgetTest.testItemDecorationAndMarginsAndOpticalBounds
In computeBitmapSize, treat padding as a size in scaleFromDensity. This
results in rounding instead of truncating. This matches the way optical
insets are handled. It also matches the padding we would have gotten if
we had scaled at decode time.
Change-Id: I7d3a83ba824b8dc81187ce9b2d9889d4a87f88ac
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: 77507530
Test: No change in behavior, no new tests
Add @Px and @IntRange annotations, and be explicit that setTargetSize
refers to pixels. Add a comment to setTargetSampleSize that is like
calling setTargetSize with particular values, to try to make it clear
how the two are related.
Change-Id: Ie7e9429bc8c548f44d382358c161425f666ba82f
Bug: 76461699
Bug: 76448408
Test: No change in behavior, no new tests
Add class level docs for ImageDecoder, including sample code. Update
wording to be more clear and less wordy. Fix broken attempts at using
sample code.
Incorporate advice at go/android-api-guidelines and
https://developers.google.com/style/api-reference-comments
Change-Id: Iaf1334993f6cd2d3f6e53d3fb70ef9c7a95c9a76
The saveLayer APIs are restored from @removed but will treat input
as ALL_SAVE_FLAGS and generate exceptions on newer API levels.
We internally used these calls in one situation that now use a
different @hide API to support the previous behavior until we
refactor that code.
Partial revert of "Remove deprecated android.graphics.Canvas APIs"
This reverts commit 7b837616ae88cbdaf12600cee23b5188e5531937.
Bug: 77276963
Bug: 73777445
Test: CtsGraphicsTestCases
Change-Id: I7acd4ffd5ac41a58d2be8b48cf50119c2b896708
Bug: 76448408
Bug: 76462125
Test: Iec21bad971dc9cffc807a412bb6329757c499baa
- Document DecodeException.getSource
- Add thread annotations
- slice() ByteBuffer inside createImageDecoder, so it can be reused
- Make ResourceSource thread safe by locking around mResDensity
- Specify that OnHeaderDecodedListener is necessary for changing default
settings
Change-Id: I3b55d3ba1b0a2276938cb521449bceb7aa9f96e2
Bug: 76448408
Test: Ib8782ff10072c81a5ed2a1031a70475fffee7ccf
- Use "is" prefix for booleans instead of "get"
- Reverse "require" and "unpremultiplied" for a more natural sound
- Add "Required" to "Mutable" methods
- Add "Enabled" to "DecodeAsAlphaMask" methods
Change-Id: I644ddccd37898d89609e4534ece4ea70f74587c4
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: 76448408
Bug: 73537624
Test: Ib40d65c68a6c709b6456f2145ad8a5557a941494
setResize is two verbs, and "resize" implies we're changing the size of
an existing object. In truth, the method specifies the desired size. So
rename setResize(int, int) to setTargetSize, which clearly specifies the
behavior.
Rename setResize(int sampleSize) to setSampleSize.
Hide getSampledSize, which looks too similar to the newly named
setSampleSize. In addition, b/76448408 suggests hiding it. It isn't
really necessary anyway, since a client can just call setSampleSize - no
need to query and call setTargetSize manually.
Since there is no way for a client to know that a RAW image couldn't be
decoded to the desired size (could previously be done with
getSampledSize), make setSampleSize do the extra scaling. This is a
better API anyway.
Change-Id: I84c29fdc6bdfb999a7f712fdc069304ae9676ba6
Copies language from <android/surface_texture.h> that connects
EGL/Vulkan presentation timestamps to SurfaceTexture#getTimestamp.
In the process, reorganized the existing language to talk about
general properties of the timestamp, and then talk about behavior of
specific producers instead of mixing them together.
Bug: 72755997
Test: make docs
Change-Id: I88253f9e23df7d7c4fe3c1c51ff2ac494da1913c
(cherry picked from commit 63d2a0e00005e9b5bb6e62d752a23ef2e43b03d4)
Bug: 73529437
Test: No change in behavior, no new tests
Document that it can be inflated from xml, and reference the attributes
that it supports.
Add a comment describing what the class does with respect to animation.
Update the comment for start() to better reflect when the callback is
called.
Change-Id: I660cbc4e185dca8bc7a43a185f91ae0485ef8753
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: 76144110
Test: I95165583649a1df86782d3684f7bf9bcd8dab7bd
This matches the behavior of DisplayListCanvas. Not scaling means that
we can draw a Bitmap to a Picture, and then play that back in HW mode
and see the same result.
Change-Id: I7421431bad0531112e06ab5c14814b6b6f1591d9
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: 74061412
Bug: 73893665
Test: Manual, I5669a97c70d726826c5c00bc1413c2f97d95d88c
ImageDecoder typically does not scale a Bitmap up to handle density.
This saves memory, and we already handle the density by scaling at
draw time. But some apps rely on the size of the Bitmap without taking
density into account. For backwards compatibility, on apps that are
built for a pre-P version of Android, scale up in ImageDecoder.
Change-Id: I9991d1286e386b47fc57bcfbf0c6652beb1a53ef
