Implement readback from Surface, TextureView and HW Bitmap
for Vulkan pipeline by wrapping the graphics buffer in an SkImage.
Refactor both Vulkan and GL readback to use common code.
TextureView readback is moved from IRenderPipeline interface to
Readback class. Refactor all 3 readback flows to use common
implementation.
Test: Passed all view, uirendering and graphics CTS tests with GL
Test: Passed many CTS test with Vulkan, that require readback
Bug: 113673613
Change-Id: Ifbfd8170a5401f87a709b4b1b9fa058e8e11768d
Fix an issue with incorrect texture matrix, when there is 90/270 rotation.
This happened, because after refactoring SkImage has buffer width/height,
instead of layer width/height.
This reverts commit a683eb3945.
Bug: 113673613
Test: Ran TextureView CTS and lensblur in camera app
Change-Id: If3bcf9cd5195de09fd67a753708568a8e3ca3a9a
Render TextureView as hardware bitmaps, instead of GL textures.
Cache SkImage for each observed GraphicBuffer, which is faster
even for GL.
Implement C++ SurfaceTexture, which allows Java SurfaceTexture
to be used with Vulkan HWUI render thread and application GL.
threads. Delete GLLayer and VkLayer classes and texture code
from old HWUI pipeline.
Test: Ran skiagl and skiavk pipeline with a TextureView app.
Test: TextureView CTS tests pass for GL pipeline.
Test: Ran Android NDK Native codec sample app.
Change-Id: Idc94f864ce2d34fd6ceff4be4fc7d3327e99879c
This fixes breakages in the WideColorGamutTests that resulted from a
change in Skia. Skia now treats all non-tagged sources as sRGB instead
of sometimes assuming sRGB_linear.
Test: atest CtsUiRenderingTestCases
Bug: 111836790
Change-Id: If7b1c00ad889446658f98e9ad644869e2eeabcdb
This CL is a ground work of the new Typeface construction API and
nobody uses this class except for CTS now.
I'll add new builder in Typeface to be able to create Typeface
from this FontFamily.
Bug: 72665240
Test: atest FontFamilyTest
Test: CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
Change-Id: I15d412c367037554d911fc9e20c0cfb44aefb89a
This CL is a ground work of the new Typeface construction API and
nobody uses this class except for CTS.
I'll add FontFamily class to be able to bundle these Font clases
and register to the Typeface.
Bug: 72665240
Test: atest FontTest
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
Change-Id: I68555a8b4bd6dd770ba7baae72d9a3777b2087a5
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
