- When battery saver changes, WallpaperThemeManager always recreate activity to reapply theme base on wallpaper color hint changes
- Battery saver change can also result in light/dark theme changes, for which WallpaperThemeManager also recreate activity to apply theme changes
- As a result, it'll be much simpler to recreate activity whenever isBlurEnabled changes
- Exposed recreateToUpdateTheme API from WallpaperThemeManager to achieved this
- Greatly simplified Overview styling to read from styles
Bug: 414789280
Test: manually toggling battery saver and light/dark theme and WallpaperThemeManagerTest
Flag: com.android.launcher3.enable_overview_background_wallpaper_blur
Change-Id: I90ad724867283fe3c62a9073a6e072491533f774
"applyDepthAndBlur" should be directly called when Opaqueness changes. When scrim is not opaque, blur should be applied to overview background and when scrimview is fully opaque, blur should be removed and set to 0.
Fix: 416686314
Test: Go to overview (live tile) when flag is off.
Flag: com.android.launcher3.enable_overview_background_wallpaper_blur
Change-Id: Iaad158ddb2f6dc89afefcd89a569a202a712ad47
Now early wakeup is controlled by BaseDepthController (with the
exception of Taskbar which uses TaskbarOverlayController). It does
all of the following:
- Increase GPU clock
- Increase CPU clock (notifyRendererOfExpensiveFrame)
- Tell SurfaceFlinger to wake up early
By default these happen the first time we render a non-0 blur, but
in some cases we can proactively activate it even earlier:
- Swipe up to All Apps begins
- Home screen QSB is tapped
These early cases were already handled for CPU and GPU, but now SF
is also in the loop.
In addition, SF early wakeup is disabled when Launcher is no longer
in the foreground.
Bug: 410973453
Test: Log manually to see early wakeup start/end
Flag: com.android.launcher3.all_apps_blur
Change-Id: I39ac0baf8c706b20f0818d31dbc8165b798ea54a
- Remove overview background scrim color.
- Create blur layer and blur surface to set blur to behind live app tile.
- Handles cases like live tile to screenshot during AiAi and orientation change.
Bug: 377244819
Test: Manual. Enter overview from app/home.
Flag: com.android.launcher3.enable_overview_background_wallpaper_blur
Change-Id: I5dce0268f4421cd0ac29dbb429e5d106da7a0bdc
The two controllers don't own any unique state, other than the current
depth state. These two _should_ never diverge anyway, because there is
only one valid depth at any given time. By using the same controller all
the time we can enforce this invariant.
Everything else is basically just registered and unregistered listeners,
which the main controller already does properly and always has the same
state in that regard as the ad-hoc one that we're removing.
Finally we don't need to take care of any cleanup explicitly, as we did
before.
Bug: 293427436
Flag: N/A
Test: manual
Change-Id: If6ea68847a60254df76e806eac2679ae0415bfe0
The same surface can become invalid, in which case we need to wait
until the next draw to apply blur
Bug: 284411563
Test: Verified on device
Change-Id: Ifb6be94756fd00c5925e11a6b7d57f206e063a17
During each app launch, a new `MyDepthController` is instantiated, which
registers two of its methods as listeners for cross window blur and
opaqueness. This controller's usefulness spans that specific animation
only, but the listeners are never unregistered. This creates conflicts
when an opaqueness signal happens, which cause the background to flicker
(see videos).
Bug: 283335820
Test: manual, see videos in the bug
Flag: not needed, bug fix
Change-Id: I3dcb0b8ff0aa77bf3183a926889d0131b17bcaa4
Showing the animation leash of appearedTaskTargets if there need to
play the reveal animation behind splash screen view.
Pausing applyDepthAndBlur while playing splash screen exit animation
from launcher side, otherwise the app window would be blurred.
Bug: 277704255
Test: manual, do quickswitch to start the app behind splash screen
view, verify no flicker or blur happen when playing reveal animation.
Change-Id: I83604ceeaeb54ab2100fdabf45a1624644b85e37
- Made BaseDepthController.setDepth/mDepth private, all get/set should be done through STATE_DEPTH or WIDGET_DEPTH
- Generified ClampedDepthProperty into Utilities.ClampedProperty to apply on STATE_DEPTH
Bug: 240580498
Test: Go to walppaper&style, set new wallpaper, then go to widget picker, wallpaper depth should transition smoothly
Change-Id: I53cdedf970fd7ffba6a952c4edf4b34251b01f07
Bug: 242746421
Test: manual
TL;DR;;
setState toState= NORMAL called when locking screen on ALLAPPS screen
but mSurface==null
hence depth is not reset to NORMAL state
Change-Id: I26a37f7de8b0ecd481b36eebf07e1b79f8b0035c
Separating the depth controller logic into a base
class so that different controllers can be used
for different surfaces
Bug: 236780815
Test: Verified locally
Change-Id: I2bd7ed50438453d6e41c73c8001a0d6a73091653
An accidental horizontal touch, due to vertical fling on the -1 screen
could lead to imperceptible change in zoom, and send a frame to client
composition. This CL adds extra padding to overlay scroll amount, to
avoid these accidental gestures.
Bug: 211245940
Test: https://ui.perfetto.dev/#!/viewer?trace_id=3260c116-c578-6dad-e047-0a327b7d346c
Change-Id: Id05e482c79c1dcc2e1ba73baf8a4a4101797bbd2
A request to set a new depth is ignored if the surface is currently
invalid. We should cache what was the requested value, so it will be
applied once the surface is valid again.
Test: manual
Fixes: 209028986
Change-Id: I812816da4b0139c7ea7b53a9fb00f11265ecdea8
- This can prevent the layered content behind to not be visible (and
since launcher draws a cutout and the wallpaper isn't shown, may
result in a black rect. We only specialize for this case while
Launcher is in Overview.
- Also don't need to defer updating drawsBelowRecents, this can result
in the state not being reflected since it runs after the last update
of the transform params
Bug: 205789573
Test: Swipe up from app and ensure behind layers are visible (also
ensure this doesn't affect blur during the swipe or optimizations
after you leave overview)
Change-Id: I07689b3d9b65708797576e5fbefe12fb1f544119
When entering BACKGROUND_APP, it's possible that the blur radius will be
lost. We need to dispatch it on the first possible frame, otherwise
Overview won't have blurs.
Fixes: 196828055
Test: enter overview multiple times
Test: pull up all apps
Test: open app from home or all apps
Change-Id: I5920e1b28e2d23421863ecd59845e902040d126c
The app window is now on top of the scrims, so we can just mark the
window as opaque and keep blurring.
Bug: 196828055
Test: atest OutputUpdateAndWriteCompositionStateTest
Test: systrace on all app, and overview
Change-Id: I128d3b4722060c0bb72a218bf01ba26dabaddacf
Until now the SurfaceControl transaction was being applied
asynchronously, which could lead to it being executed out of sync with
launcher drawing.
This became an issue at higher refresh rates, where frames are produced
at a much faster pace.
In order to fix this issue, we can use BLAST transactions, which are
annotated with a frame number.
Test: record video, go through it manually
Fixes: 194320152
Change-Id: I1636a1ded4f9dd84c54ba12239e3549b92ed7567
The scrim visibility drives whether the launcher window is opaque or
not. We should track it and apply the flag instead of trying to catch it
through other Launcher life cycles.
Fixes: 195365607
Test: tap on home button while launching app from overview
Change-Id: I2a00b86b602b5dd12c901433b92adcf0170be15e
Otherwise events won't be dispatched properly and window opacity will be
wrong.
Test: manual
Fixes: 191149025
Change-Id: Ice7ea86252282c7dc1cb5925dd1bdb8cade89c08
We'd like to be able to disable blurs during app launch, but without
disabling zooms as well. The previous sysprop would set the depth of
BackgroundAppState to 0, when what we want is to conserve wallpaper
zoom.
Bug: 191969790
Test: adb shell setprop ro.launcher.blur.appLaunch false
Change-Id: Ie4b26096f6ac723c3981bba2829557e6cc6c733b
We need to update mDepth even when the surface is null, otherwise
events will be ignored and mDepth will have the wrong value when
waking up from screen-off.
Test: pull up app drawer, screen off, unlock
Test: go to overview, screen off, unlock
Test: launch app, observe blurs and zoom
Fixes: 191153501
Change-Id: I33f5d84a50e24f05a09769b1f7f3c27969f847cd
The App window will be under Launcher, so we can't actually blur
launcher at that time, otherwise the live window will also be blurred.
Test: manual
Bug: 189207458
Change-Id: Ie07449d29d3b0dc60d3787b6d32aa9e46e0bb613
This will help with overdraw, because we don't need to draw the
wallpaper.
Test: manual
Test: adb shell dumpsys SurfaceFlinger --timestats -dump
Bug: 187703092
Change-Id: I2ebae94725578e5f4d640cd6b45da3f4d1f21a20
- Also no longer resets depth on surface change, as depth is independent
from blur.
This fixes the bug where depth is not accurately reflected.
Bug: 185680609
Bug: 185189176
Test: launch app and swipe home multiple times
launch app and back gesture to home
Change-Id: I5e2f4ce08b8bf84b7356fbd080ae732875c5e04e
- Remove PLAY_ATOMIC_OVERVIEW_SCALE and PLAY_ATOMIC_OVERVIEW_PEEK
- Remove complicated parallel atomic animation support from
AbstractStateChangeTouchController and subclasses
- Remove some code related to going between Overview <-> AllApps
Test: Swipe between states in all 3 navigation modes
Bug: 175137718
Change-Id: Ice314d46946c3a983cdc6ccf1a67effb5da9156e
This is a workaround until we can support app transitions when starting
an activity in mw mode.
Bug: 158613217
Change-Id: I843d6669722c543728ab532e1c4fbd4643f6f135
This "fixes" the bug where wallpaper zoom does not reset to 0 when
screen turns off since we no longer require a valid surface to set the depth
when blur is disabled.
Note that the bug still exists when blur is enabled, which will need to be
fixed in a follow up CL.
Bug: 157946272
Change-Id: I43179435885c95eb2ecf406fa5c291badf5a1ed3
Alex Chau
vinayjoglekar
Andy Wickham
Fengjiang Li
Anushree Ganjam
Luca Zuccarini
fbaron
Sunny Goyal
Kateryna Ivanova
wilsonshih
hyunyoungs
Lucas Dupin
Winson Chung
Jon Miranda
Tony Wickham
TreeHugger Robot