Bug #8066455
ViewRootImpl was properly detecting that the renderer was not
ready to draw but would simply schedule another frame, thus sending
the systemui into an inifite redraw loop. This change reinitializes
the renderer if needed (if the renderer is requested but not enabled.)
This CL also fixes an issue caused by the default wallpaper. Since it
never calls eglTerminate(), managed contexts are never reclaimed.
Change-Id: Idb8caa672be8ee35f6e6a7e942d9abd8aa100967
ImageWallpaper runs on the main thread now and doesn't need to add
callbacks on different threads or lock against concurrent access.
Bug 7326921 fixed.
Change-Id: I6097e1dff8af743a4fb81b697efee0e02667125b
Give the GC a chance to collect the current bitmap if it needs to,
as it allocates memory for the next one. This helps avoid OOM situations
that can sometimes occur in extreme circumstances (huge bitmaps)
Also set the default_wallpaper to the right default size.
Issue #7352961 Wallpaper edge is cut-off while scrolling through home page
Change-Id: If76b55061d04b29af7f66a6162e307b8b53bf4ae
Previous logic compared the surface size to the bitmap size to determine
whether to reload the bitmap. This was based on an assumption that the bitmap
would be created at the same sizea s the surface. However, the process of
how those sizes get determined is different for surfaces and wallpapers, causing
an occasional issue where the bitmap gets reloaded frequently, every time the wallpaper
is asked to redraw, even though it always gets recreated at the same size.
New logic checks previous surface dimensions against current surface dimensions to
determine whether the bitmap should be reloaded; we really only want to reload
it when the surface size changes.
Issue #7373200 pause when toggling between All Apps and Home screen; Home button stays illuminated for a long time
Change-Id: I108777b72bd42616ad7cf8274af1b3e6b2ed94e7
Typo in ImageWallpaper made a dimension check incorrect.
Issue#7373200 pause when toggling between All Apps and Home screen; Home button stays illuminated for a long time
Change-Id: I82763ac8c9ed564eba904f552975ab20c8aef932
Switching users causes wallpapers to get recreated 3 times. Other operations
like startup and rotation cause similar redundant load/draw operations. This change
tracks the various attributes that tell us when we really need to reload
and redraw, causing only one of these expensive operation per one of these
switches.
Issue #7334664 Wallpaper draws several times when switching users
Change-Id: Ic3072ef3a7eaf622d8632e87e34f50999f716c39
Update the wallpaper and redraw it unconditionally when the surface
changes. Previously we were not updating the wallpaper when the
surface changed which meant that it remained at the original surface
dimensions. Also, the indication that it was visible comes in too
late to display it cleanly without jank.
Bug: 7310334 fixed.
Change-Id: Ic2ae95ea0b0704183053da1d7a906818651c62c9
Screen rotations force static wallpapers to get recreated. One of the things
that happens is that the underlying bitmap resource is loaded. This can be quite
expensive for large bitmaps (which is the case on large-display devices).
A simple optimization is to retain the bitmap in the wallpaper process, to avoid
this re-loading step. We still re-draw and re-upload the texture, but at least
we don't re-load the thing.
Issue #7324823 Manta wallpaper decode performance is atrocious
Change-Id: I0748e275a55992d13704a7dec5910d2dbdc9e2a4
Split WindowManagerImpl into two parts, the WindowManager
interface implementation remains where it is but the global
communications with the window manager are now handled by
the WindowManagerGlobal class. This change greatly simplifies
the challenge of having separate WindowManager instances
for each Context.
Removed WindowManagerImpl.getDefault(). This represents the
bulk of this change. Most of the usages of this method were
either to perform global functions (now handled by WindowManagerGlobal)
or to obtain the default display (now handled by DisplayManager).
Explicitly associate each new window with a display and make
the Display object available to the View hierarchy.
Add stubs for some new display manager API features.
Start to split apart the concepts of display id and layer stack.
since they operate at different layers of abstraction.
While it's true that each logical display uniquely corresponds to a
surface flinger layer stack, it is not necessarily the case that
they must use the same ids. Added Display.getLayerStack()
and started using it in places where it was relatively easy to do.
Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
Add permissions for various things it pokes. Create new permission
to control launching non-exported activities from recents. Hidden
API to relax WallpaperService checks.
Change-Id: I547fdcd7c213dd153ae101533ce7c56cd8f86a0d
Inside drawFrameLocked, updateWallpaperLocked() is called after
calculae drawing offset using mBackgroundWidth/Height. Because
mBackgroundWidth/Height is modified inside updateWallpaperLocked(),
it sould be called before Mbackgroundwidth/Height is used.
Many market launcher and some phone vendor launcher call
suggestDesiredDimenstions with argument (w,h) instead aosp's
original (w*2,h) for single page wallpaper. In that case, when
launcher orientation changed, ImageWallpaper does not properly
display wallpaper image and mostly you can see Black Edge at
left.
Change-Id: I93ebc4337b01f73d3154346943afa4afd6b1988a
Swiping the home screen causes the WindowManagerService to do
a bunch of work to keep the wallpapers in sync. First, it lays out
and places all windows. Also, it notifies the SystemUI process that
the wallpaper position has changed.
The layout/place operation is too much work - we only need to set
the position values for the wallpaper, not relayout the whole system.
The notification mechanism must exist, but should be optional. Most
wallpapers don't care (especially static ImageWallpapers). So we'll
give them a new API (WallpaperService.Engine.setWantsOffsets()) to
allow wallpapers to opt out of this process and avoid the performance
overhead.
Change-Id: I66c38375438937f14f6f5550565b28eb204b1e06
Take care of updating from old component name, and don't let this happen
again.
Also tweak how we switch between static wallpapers to avoid introducing
a 4MB allocation in the system UI process when this happens -- we now
stop the current wallpaper service and start a new one, so we get a
brand new surface that we can draw only one time in to.
Change-Id: I6fc8a42b8a46bba79759bd68fb7d0684b5d897b7
Nice to not load 4MB bitmaps in the system process.
Also, hey, with how we are now scrolling the surface instead of
the bitmap, there is no reason to keep that 4MB bitmap loaded in
to memory. So don't.
Unfortunately it looks like for some reason the VM is still
holding on to the bitmap. I'll need to figure out why. Later.
Change-Id: Ib3503756144502fc5c8d5e294248c2417c4fe8c8
