uniforms are no longer set as single block of bytes where the caller
has to know the offset, but instead by the string identfier in the
shader. This CL only supports floats, but future expansions of this
will provide helpers for ints, colors, and byte[].
Also by storing the shaders and uniforms in the RuntimeShaderBuilder
we can more easily copy them. This enables Canvas.drawRipple to not
just copy the compiled SkSL effect, but also all the uniforms and
other input shaders set on the RuntimeShader.
Bug: 177051137
Test: HwAccelerationTest
Change-Id: I4733f42ba662546be6bebc37f0b89832778e66ce
When format is changed, there's no need to preserve surfaces. We can
just update the consumer to use the new format. There shouldn't be any
issues since the next dequeue will get a buffer with the new format. The
current buffer on screen won't change and the layer properties aren't changed
when format is updated. There's no need to recreate a new surface.
Instead, move the format updating logic to the client in VRI and send
the new format to BLASTBufferQueue so it can update the consumer.
Test: go/wm-smoke
Bug: 177557720
Change-Id: I26806cfd4b482e8b6165045f4af3c55a5955da0c
Keep the actual display list type internal to HWUI/native
avoids requiring that the recording type fits in a jlong
aka, opens up a usage of value types here instead
Test: boots
Change-Id: Idf5a4acc7dbcb61e6742a6bf6369bd351f595be4
This is in response to API feedback - dump() methods for most of the
public classes describe complex internal state, which does not fit for
the Point class. Point#dump does not need to exist anyways, because
1. Point#toString exists, and
2. Point#dump only printed out the x,y coordinates, which are already
part of the public api, so printing out a more concise string
representation is trivial.
So, this patch removes Point#dump and just has RemoteAnimationTarget
implement its own print method for Point, since it was the only caller.
Bug: 159683987
Test: builds
Change-Id: I5c947330768b3e4e450eba3971de939a904d30d4
If updatable font dir is provided by caller and fonts exist in the dir,
FontListParser will use the updated fonts.
Currently, updatable font dir is used only in test.
Bug: 173619554
Test: atest TypefaceSystemFallbackTest
Change-Id: I631764fe235d258b6b5cb6d6906c17d48c7e4608
This also adds the ability for RenderThread to animate a few
predefined shader uniforms.
Bug: 177051137
Test: demo in ag/13296877
Change-Id: I6e58e671ad1242a07ecb1cf4cdb48031f85c2088
-Added documentation on RenderEffect usage
-Updated documentation regarding coordinate space
of dst rect to be within bounds of target
RenderNode
-Updated createBlendModeEffect documentation to
remove references to nullability since the parameters
are required to be non-null
Bug: 173657415
Test: N/A
Change-Id: Ief136650e40d1b820de9e175ac906f87c67ea864
Usage has been discovered by an app so reverting this to its previous
state. This is conceptually a partial revert of change 5d123b6775.
NoNonSdkCheck: b/170729553
Bug: 176388660
Test: m
Change-Id: I4399e4d431f8a443343de312e131fbf86d0f60b5
Usage has been discovered by an app so reverting this to its previous
state. This is conceptually a partial revert of change 5d123b6775.
NoNonSdkCheck: b/170729553
Bug: 175939224
Test: m
Change-Id: I277b085b490407bbe1899dd7f4614f51cd9ce36e
Currently SV with blast sync requests a sync transaction from VRI and
merges its transactions with VRI's sync transaction. This can break if
we are not able to set the request in time.
Instead this change will merge SV transaction from the renderthread to
the VRI BlastBufferQueue specifying the framenumber which the
transaction should be merged with. The transaction will be queued until
we submit a VRI buffer with the requested frame number.
Test: open bubbles with sv blast
Test: atest SurfaceViewSyncTest
Bug: 175594838
Change-Id: I87ba346d782f615bab2e8a692adb2b3c49ef4021
The issue is the following:
1. Call relayout from VRI. drawsNeededToReport = 1
2. SV also will need to be updated. drawsNeedToReport = 2
3. VRI is finished rendering, but SV is not. drawsNeedToReport = 1
4. VRI calls relayout again. drawsNeedToReport = 2
5. SV finishes drawing. drawsNeedToReport = 1
BBQ will get stuck since it's waiting indefinitey for a transaction
callback. The previous transaction can never get applied since we're
still waiting until drawsNeededToReport = 0.
This prevents situations like this from happening since it will not
allow a relayout to get called until the previous transaction has been
applied.
Test: Split screen with chrome
Bug: 167202096
Change-Id: I167a90ef00fa6677b3c55239e74eefb6a1384baf
ActivityThread.mBoundApplication has @UnsupportedAppUsage, so apps can
re-send BIND_APPLICATION message with the same AppBindData by using
reflection.
Bug: 174969232
Test: manually tested with the test app in the bug
Change-Id: Ic96d670f6346d9d1373607b4ae6e78b78194a09c
Bug: 174932174
Test: None
We are already OWNERS of the native side (libs/hwui), and we are active
in the development of the Java side as wel.
Change-Id: I3727411e0123b80843fc6f936b8b3700c8943825
Added View API to configure RenderEffect on the underlying
RenderNode
Bug: 159712515
Test: Added CtsUiRenderingTestCase
Change-Id: Ic64009ac79927d61c7c1f63306ced3da18fce1da
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script from
detailed ownership information confirmed by team leads.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Change-Id: I9789c97c1de8e5d962b48c29c57d82fe83729eba
