Revert "Add tests to ensure hardware only for RuntimeShader API"
Revert submission 16475336-RuntimeShader_softwareOnly
Reason for revert: Breaking tests as system is dying
Error: Software rendering doesn't support RuntimeShader
Bug: b/211066630
Reverted Changes:
Id0ee4d1f0:Enforce that RuntimeShader is only hardware accele...
Ib4c2e54bd:Add tests to ensure hardware only for RuntimeShade...
Change-Id: Id7bbf2609a06c1cd69f6a457dab44f9478d95742
Throw an illegal argument exception any time a Paint with
a RuntimeShader is attempted to be drawn into a software
canvas. Also mark that a Picture that uses a RuntimeShader is
properly marked as requiring hardware acceleration.
These tests check that the use of RuntimeShaders trigger
Bug: 189102731
Bug: 201546136
Test: atest CtsUiRenderingTestCases:RuntimeShaderTests
Change-Id: Id0ee4d1f05e2975031121298b45f925ee74f6818
In addition to exposing the API to the SDK this CL expands the
number and type of APIs available to modify the uniforms. For
uniforms that resolve to the primitive types of 'float' or 'int'
there are five different entry points for each whose purpose is
twofold. First, these entry points map directly to the GLSL
types (e.g. float, vec2, vec3, vec4, float[]) that these uniforms
are bound to. Second, for animations these uniforms can be updated
every frame and avoid unnecessary java array allocations was also
motivation for using this pattern instead of varargs.
Bug: 189102731
Test: atest CtsUiRenderingTestCases:RuntimeShaderTests
Change-Id: I4870acd7656095c9d413e708a3150c10134e8afd
Clipping Views to Outlines has existed for several releases,
as has providing a Path for shaping Oulines. However, using
a Path-shaped Outline to clip a View against was specifically
disabled internally, due to historical functionality limitations
(prior to enabling Skia for HWUI rendering) as well as performance
concerns.
On current (even relatively low-end) hardware, path clipping is now
sufficiently performant that we are enabling this functionality.
This functionality will be used by AndroidX APIs that enable easier
shaping via paths.
Bug: 201807515
Test: Manual testing including hwui performance tests and CTS
OutlineTest
Change-Id: Ic61d9393cb72c6ad3517954177e5037a383a0c4d
Fixes a case where the SurfaceView is stuck with a wrong
scale.
Destination frame scales the buffer to the SurfaceView
fixed size. Currently the initial destination frame is
applied when the first buffer is acquired by BBQ. The
transaction is sent via the BBQ apply token.
Meanwhile if the client updates the SurfaceView fixed
size, the SurfaceView will apply the transaction via
the SCC apply token.
This can cause destframe changes to be applied out of
order causing the app to be stuck with the wrong
scale.
Bug: 195443440
Test: atest BLASTBufferQueueTest
Test: repro steps from bug
Change-Id: Ibf53a0efdebb87291d081e48633c373a98d347b1
When the main window gets a configuration change, the new buffer for the
SV will get applied in the same transaction as the main window. This
will allow apps to implement seamless rotation without a frame or more
of black where the SV was resized, but the buffer was not yet updated.
This also includes an optimization where if only SV change occurs, but
there was no request from WMS to report drawing, VRI can apply the
transaction immediately without reporting to WMS.
Test: SV with seamless rotation enabled
Bug: 200284684
Change-Id: I5569d815eef92acf3bf9d7f753bd5ab94a332cfe
Also implement getDataSpace functions in SurfaceTexture and Image field
to help with upstream HDR work.
Bug: 201539996
Bug: 201535454
Test: android.hardware.camera2.cts.ImageWriterTest, android.hardware.cts.DataSpaceTest pass
Change-Id: I17fa43c1ba60e6f59da1910cebcef0dab993ce3b
The variable nextTransaction is abigious and doesn't represent its
purpose. Rename to syncTransaction
Test: Builds
Bug: 200285149
Change-Id: I55c3efe02aee17a610034bb5eb011e98e7747d7c
There are no longer an uses for BBQ.setTransactionCompleteCallback so
remove from code.
Test: Builds
Bug: 200285149
Change-Id: I1eea54ac53b4f8514ea11116e6839a39acf51e68
For P010 format, Each pixel has Y and subsampled CbCr. So:
bitPerPixel = 1.5 * bitPerPixelY
bitPerPixelY = 16 bits
Bug: 200949749
Test: Camera CTS
Change-Id: I7964d64c25961dbef634ac1ef82898147ec57111
flushShadowQueue no longer does anything in BBQ so remove from Java and
JNI code.
Test: Builds
Fixes: 199204968
Change-Id: I4df67a23732ba4ffaca42390b29d3f81cadd6457
It's possible for a caller to requested mergeWithNextTransaction, but
the main frame had nothing new to draw. If that's the case, the
mergeWithNextTransactions will be stuck and never applied (or applied
much later). Since this could end up blocking Transactions, it's better
to force apply these when we know a frame wasn't going to draw this
vsync.
Test: Existing tests pass
Bug: 195262673
Change-Id: Ic0919ba6446d6a12d824185f6b3e540c2d5319d7
SkSL syntax is evolving to better communicate how the effects integrate
with the rest of the Skia pipeline. 'sample' suggests texture sampling,
but the invocation of the shader object is really a call to a function
(the entry point of the SkShader's generated code).
Bug: skbug.com/12302
Change-Id: Ib6b895208ae70368901965b7ca13434c51a7455f
The previous code waited for a frame complete callback from hwui before
notifying WMS that a draw had occurred. However, frame complete callback
was not guaranteed to get called since it only invokes a callback if a
draw actually occured. VRI really needs a signal that RT has completed,
since it just needs to know that a draw was possible so it can notify
WMS that the RT completed its pass.
Instead, rename frameCompleteCallback to frameCommitCallback since that
API is exposed to a public API when a frame was actually drawn.
Create a new callback, frameCompleteCallback, that is invoked when the
draw has completed, regardless if a frame was actually drawn.
When the frameCompleteCallback is invoked, VRI can check to see if a new
frame actually drew. VRI can call into BBQ to see if the frame acquired
matches the frame that was attempted to draw. If so, VRI can wait on a
transaction callback. If not, it can allow VRI to continue. In either case,
it will notify WMS that the draw has finished.
Test: Split over and over
Bug: 195262673
Change-Id: I24dd19ab2746be3fc33e597761abf8c5249f8b5b
The FontFamily will be removed if none of font files exist on the
device.
Bug: 192479819
Test: atest FontListParserTest
Change-Id: I36f6476fe37bc04ec8737936747385c63908d651
(cherry picked from commit 691cfe8818)
The initial commit of the @Nullable annotation appears
to have been based off of the javadocs. However, the actual
code does not appear to have allowed for null at that time.
It's not entirely clear if null was ever allowed, but it
hasn't been allowed since API 14 at least
Test: make
Fixes: 195924626
Change-Id: Ibffdc7b90cbfc3bc65a4a08bee52e2e3412bed3e
Some vendors may prefer a different underlying layout for P010 in the
future compared to the one currently supported in gralloc. In
particular, it's not a guarantee that the CB/CR plane is contiguous in
memory with the Y plane.
Bug: 195570363
Test: builds
Change-Id: I01eea78b8555610470959cdb4f0f9ceb16e80f73
Bug: 195281495
Test: Ief7025c21f365ae90fa63120f1cc82e0695901af
This is a partial revert of 47c51fe80e3dd9d6b518c11c2e1714c271835af5/
I5d5d03e430af380e23016c6deba5eca46067a22b. The intent was to bring
today's rendering implementation in line with the old HWUI
implementation, which always dithered gradients by default. However,
when dithering is enabled, the Skia implementation dithers more than
just gradients (e.g. Bitmaps). Combined with poor performance of the
dithering algorithm on certain GPUs, this led to a performance
regression on key apps.
Change-Id: Id54121091e2cc47131dc9b5ae67bd638fbc005fc
Apps that create RippleDrawable on a background thread could crash,
making them incompatible with S.
Test: manual with MindBody app
Fixes: 194952073
Change-Id: I9d16d5c63c192e96191b4fbc859ff3bc3da733cb
Don't try to do a RenderNodeAnimation if the RenderNode
isn't attached. Although this isn't strictly speaking a
valid state to be in, it's also easy for RippleDrawable
to just ignore it.
Bug: 186864959
Test: ripples still show up, are still RT accelerated normally
Change-Id: I8127f1419508157eb83ac9bb1562745ac53d2ced
1. Change mGradientColors to a ColorStateList array
2. Update mGradientColors array by reading the Theme and XML color in UpdateGradientDrawableGradient function
3. Query state color in each instance of mGradientColors array in
ensureValidRect function for LinearGradient object creation.
Bug: 157969624
Test: android.graphics.drawable.cts.GradientDrawableTest suite
Change-Id: Ibbf2c5cb2846d75c53bd34a3f04661ae604e6745
