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
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
Without this, when font are overlayed it will fail because it is looking
in the wrong place to load the font
Bug: 151770185
Test: Manual, example app that has a font that is overlayed
Change-Id: I64c5a436b7250cfd0a75f5de36c64f07a20d523a
1) Update the LineBreakConfig class to be immutable.
2) Do not return null in the PrecomputedText.Params#getLineBreaiConfig API
Bug: 216638444
Test: atest TextViewTest; atest MeasuredTextTest; atest PrecomputedTextTest; atest TextViewPrecomputedTextTest; atest StaticLayoutLineBreakingVariantsTest
Merged-In: I93bcb6ebc35344e34e9bb8a24df375aa7b3a8d81
Merged-In: I07766137ff6639c7d4acaad07dbcf11a2841cdb0
Change-Id: I07766137ff6639c7d4acaad07dbcf11a2841cdb0
They are now public API, so they should perform the same checks as in
respective calls with ASurfaceTransaction.
Bug: 210837722
Test: atest SurfaceControlTest
Change-Id: I1f17f8402dc116a419189f31faf351ffa967ecda
Modified SurfaceView and ViewRootImpl to provide callbacks when syncing
a transaction instead of sending transactions. This will ensure a clear
ownership of the transaction object since it will be provided in the
callback when BBQ adds a buffer into the transaction. Modified JNI to
add compatibility for native functions.
Test: Manual testing from go/wm-smoke.
Test: BLASTBufferQueueTest
Bug: 210714235.
Change-Id: I1f872d6b2846b0d64d5b33b8866d0b2ec7126c8c
For Android S, we use the API windowSplashScreenAnimationDuration to
know the duration of the animatable icon would be, however, developers
can be confused to thought that this API is used to declare the
duration of splash screen.
To get the real duration of the animatable icon, if it is an AVD or
AnimationDrawable, try to get the animation duration from it.
Test: atest StartingSurfaceDrawerTests SplashscreenTests
Bug: 211707095
Change-Id: Ia3f8c5cd50bab164360e07d9ced87ff7f4321e96
The caller such as SurfaceView can optionally apply destination
frame changes if they wish to synchronize buffer scale with other
scales in the hierarchy. This is hard to synchronize if the buffer
scale changes, since in fixed scaling mode we want the destination
frame to be applied when a buffer of the new size is queued.
This approach is brittle because SurfaceView does not have control
over the buffer production and the app can get into a scenario
where there is scaled incorrectly.
Fix this by configuring BBQ to always apply destination frame
changes or always defer to the caller. If the scaling mode is freeze,
then BBQ will set a flag to ignore the destination frame. This
allows us to synchronize destination frame changes with scale
applied by a parent and avoid unwanted scaling if the scaling
mode changes to freeze.
Test: atest SurfaceViewTest
Test: go/wm-smoke
Bug: 217973491
Change-Id: I5226c304bae9dde890306f8528dfeabf6b015a32
Also fix a typo in ImageFormat's docs
Fixes: 218928677
Test: make
Change-Id: Icc5d32afac113e639a81a11c86bee1698ef12861
(cherry picked from commit 000c374e2b)
Call the updated native version of getDisplayDecorationSupport (added in
I961051c0a660b596039ac04b546040764ee20d34), and convert the NDK struct
into a Java class. Depend on the graphics AIDLs, which now have Java
backends. A future CL will update SysUI to call the new API.
Add a PixelFormat for R_8 to correspond to the native version. This will
allow SysUI to use COLOR_MODE_A8 when the HAL reports R_8.
If64fd6924960f592b7a211371bc2ca6536ae34f7 demonstrates using this.
Bug: 216644902
Test: manual
Change-Id: I0e34c6d6e369fda0a96231ab38c3bd5f3bfe3e06
Instead of applying the pending transactions when a frame wasn't
rendered, we gather the transactions and merge them with the transaction
that will be used to sync. This is to ensure these frames are sent to
the caller that requested the sync so they can ensure it's applied at
the correct time.
Test: Builds and run
Bug: 200284684
Change-Id: I087c67138f31cc93e79df42c29464ab4f7989d52
Also change DataSpace from long to int (HAL & native are both ints)
Bug: 217776226
Fixes: 218320444
Test: make && SurfaceControlTest#testSurfaceTransaction_setDataSpace
Change-Id: Ic2b9ccb1d0ba3c1d049839310b4fef0881a3d2e2
Skia can now detect this performance optimization
automatically so there is no need to increase the
exposure of the public API.
Test: atest CtsUiRenderingTestCases
Bug: 201546136
Change-Id: I5f80259530a08506f54cef59b4b1940e940bfe91
I inferred nullability annotations in Jetpack based on the guaranteed
behavior of the platform, so now I'm propagating those inferences back
to the platform as annotations.
Test: nullability presubmit checks
Fixes: 206801689
Change-Id: If969bbe8a2263a3dd6cc1497a01354648a8795e9
