The optimization has bugs and is of questionable value
given the current state of JNI. Just remove it.
Fixes: 149585703
Test: uirendering CTS, Path graphics test
Change-Id: I613e4854695ae6e4ad9ec8b17be44e856ed03860
Also make it actually async, and allow the bitmap
to be auto-allocated
Bug: 195673633
Test: PixelCopyTest CTS suite
Change-Id: Ie872f20c809eaaeb8dc32f3ec6347f21a9a7bc1a
clipPath is already anti-aliased since Android S, so we do not
need to create extra bitmaps for this
Bug: 211896569
Bug: 238937089
Test: Updated tests / presubmit
Change-Id: I60ce42d91ca96babbde9faa4e5580b00f681de35
This saves ~31 KB per process on oriole.
Bug: 174672300
Test: atest CtsGraphicsTestCases:android.graphics.cts.TypefaceTest
Change-Id: Ic70ea842985a0aca441a31327e41980ed47bc961
This new method computes the horizontal character bounds by making
use of the character advances returned from native layer. It'll be
used in TextView to populate character bounds, and it's much efficent
compared to calling getPrimaryHorizontal for each character.
Bug: 233922052
Test: atest android.text.TextLineTest
Change-Id: Icdd53e61e2d1513b2231affb19bb00ea5d938d48
This adds tracing to ImageDecoder for image loads. When a drawable is
being loaded, it'll emit a short description of the resource and desired
loading sizes. This will make it significantly easier to find large,
slow bitmap loads when debugging regressions.
Bug: 235451049
Test: physically on a Raven device
Change-Id: I615342f1bd11d867e0bd33209507330848df8525
Lower the background opacity when the window loses focus
while the view still has focus, in order to prevent user
confusion in a multi-window environment.
Bug: 230355625
Test: manually verified
Change-Id: I59cd7faf35f05a12451f015f8ef2da47077b1bf2
Merged-In: I59cd7faf35f05a12451f015f8ef2da47077b1bf2
Lower the background opacity when the window loses focus
while the view still has focus, in order to prevent user
confusion in a multi-window environment.
Bug: 230355625
Test: atest RippleDrawableTest
Change-Id: I59cd7faf35f05a12451f015f8ef2da47077b1bf2
Before this CL, minimum dimensions of Activity wasn't respected,
that said, an Activity could be embedded in a TaskFragment of which
bounds are smaller its minimum dimensions.
This CL add the minimum dimensions on several places:
WM core:
1. Verify minimum dimension requirement before adding an Activity to
a TaskFragment. It'll be early return if the requirement is not
satisfied.
2. Propagate the minimum dimensions to the client side through
TaskFragmentInfo to notify the requirement.
3. If TaskFragmentOrganizer tries to shrink a TaskFragment to
the bounds that smaller than minimum dimensions of its children
Activity, switch to match the parent bounds.
AndroidX Window extensions:
1. Early return if TaskFragment is resized to the bounds that smaller
than minimum dimensions which dispatched from the server side.
2. When organizer tries to show Activities side-by-side, verify if
minimum dimensions requirement of the primary Activiy. If the
requirement is not satisfied, show Activities in fullscreen
instead.
TODO: Add an API to check if an Activity intent is allowed to embed
in a TaskFragment.
Bug: 232871351
Test: atest TaskFragmentOrganizerControllerTest
Test: atest TaskFragmentOrganizerTest TaskFragmentOrganizerPolicyTest
Test: atest SplitActivityLifecycleTest
Test: atest CtsWindowManagerJetpackTestCases
Test: atest WmJetpackUnitTests
Change-Id: Ib46c2cec2a0735b9e3f3420f2cb94754801b86b9
Update View logic to cancel all RenderNodeAnimators
when it is detached from a window.
Updated HWUI Animation logic to enable a cancellation
flag to cancel all animators operating on a RenderNode
whenever the staging parameters are pushed to RenderThread
Fixes: 229136453
Test: Added core test to RenderNodeAnimatorTests
Change-Id: Id674e8474757bfc8dfe30394dde29da49d139bfc
When the size of the drawable bounds changes, the mask shader is not updated properly
Assumed passed by reference instead of pass by value which resulted in
the wrong behavior
Fixes: 227624349
Test: RippleMicrobenchmark
Change-Id: Iedc3f06441414455fcfedf8cabd61e5b334a7441
This reverts commit 47032a2095.
Reason for revert: DroidMonitor: Potential culprit for Bug 230140012 -
verifying through ABTD before revert submission. This is part of the
standard investigation process, and does not mean your CL will be
reverted.
Change-Id: I22f5aa5bd57e37d638292773986b479428e5cdbc
The nGetReleaseNativeFont native method has been moved to the enclosing
Font class. JNI registration also does not occur for
Font$Builder.nGetReleaseNativeFont.
Test: m -j framework
Bug: 230032992
Change-Id: Ic987812cabe57c5c964b3cb8036cd7e297c11c36
Because Bitmap mutability is propagated across Parcel and Binder, the
following problem can happen when sending an Icon containing a Bitmap
as part of a Notification:
1. App creates Icon with a mutable Bitmap (1 alloc)
2. App sends Icon to system_server, often creating ashmem Bitmap (2 allocs)
3. system_server converts ashmem Bitmap back to heap Bitmap (3 allocs)
4. system_server sends heap Bitmap to each NotificationListener individually,
converting the heap Bitmap to ashmem each time (3+N allocs)
5. NotificationListener converts ashmem Bitmap to heap Bitmap (3+2N allocs)
This is inefficient. This is especially bad because the API to update
a Notification involves sending a full Notification object, including
Icons, repeatedly, and some apps do that several times per second.
Instead, ensure that all Bitmaps transmitted as part of Icons are
immutable. Instead, we get:
1. App creates Icon, which may copy to immutable Bitamp (1 or 2 allocs)
2. App sends Icon to system_server over ashmem (still 1 or 2 allocs)
3. system_server uses received ashmem Bitmap directly (still 1 or 2 allocs)
4. system_server sends same ashmem Bitmap to NotificationListeners (1 or 2)
5. Each NotificationListener uses the same ashmem Bitmap (1 or 2)
This solves the per-NotificationListener amplification, but it does
not solve sending what is likely the same Bitmap N times per second
when apps update Notifications. That will require either app changes
or Notification API changes to avoid bytewise comparisons for all
Bitmaps.
Test: boot, notifications work, memory in maps/gearhead remains good
Bug: 227920378
Change-Id: If92835f647a76da599f358c7c02888e3e2f59235
Native machinery now reports queue stalls from native layer
up to java layer, which can more appropriately handle errors.
The first case we handle is the case of "stuck fences", generally
indicating GPU hangs. In this case we trigger a bespoke ANR rather
than waiting for an ANR in dequeueBuffers later. dequeueBuffers
ANR could have any number of causes, and this large cluster
is difficult to debug.
Bug: 216160569
Test: Existing tests pass
Change-Id: I7b4429ce96d0bbfa1b74534ddf2b447facb22d10
In most cases, we do want the destination frame to be updated by BBQ.
The exception is SV due to multiple threads involved in property
changes. Change the default updateDestinationFrame to true and let SV
set it to false for their scenario.
Test: Apps with NATIVE_WINDOW_SCALING_MODE_SCALE_TO_WINDOW work
Fixes: 228008717
Change-Id: I90ae6f0797633aa963c540a94f1cbaea9e498f23
The forceDraw flag in HardwareRenderer will ensure a frame is drawn when
requested even if it would end up drawing multiple frames in a single
vsync.
This is to help blast sync when we want to synchronize the
buffer. We want to make sure we are guaranteed a callback since we don't
want to wait for retries, especially in the case when trying to synchronize
multiple buffers.
There was already a global flag to handle this, but would use the flag
for all draws. This new function is set per draw so once a frame is
drawn it's unset. The global flag was only used for tests so updated the
test to set the flag before every draw and deleted the global property.
Test: Underlying code was in place. This is just piping a new setter. No
usages yet.
Test: TestSceneRunner
Bug: 200284684
Change-Id: Ie1c9950cabb7331cfed1721564a51a1a15cd1624
HWUI already supports disabling RT animations, but there was no correct
way to call it from the application. Adding a call to enable or disable
RT animations on the RenderThread so RT animations can be disabled
during a blast sync.
Test: Builds
Bug: 200284684
Change-Id: Ia1ae3498c38b84b4975f08d37bc764f0c690ed9f
