doesn't happen because the visibility never changes. With this change
the overlay parameter and position will be committed when either the visibility
of the window changes, or on the first call to visibility resolved, if it
hasn't already been done.
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
Merge commit '58ebdcc06eca06741460a7db2be4b79e3865eb88'
* commit '58ebdcc06eca06741460a7db2be4b79e3865eb88':
fix [1947273] the DimLayer causes the whole screen to update during transactions
we can't use a texture of 1/4th of the screen for the dim layer, because the mdp internal input resultion is alwyas integers and for very small blits of a couple pixels the scale factor can get way out of range, for instance for a 7 pixels source, the scale factor would be either 7 (7/1) or 3.5 (7/2) instead of 4 (7/1.75). This caused the mdp to fail in some cases and revert to software. we now always use a texture of the actual screen size, so the problem will never happen. This burns 300KB of pmem instead of 21KB. On devices with a larger screen we might want to use a smaller texture and tile it by hand.
Merge commit 'b1cdb64877ebd3b8c5182913ff02edd8b54a6982'
* commit 'b1cdb64877ebd3b8c5182913ff02edd8b54a6982':
Allow the qemu.sf.lcd_density property to override the value of ro.sf.lcd_density
ro.sf.lcd_density is usually defined in the build.prop file which is parsed by init
before anything else. Since its name begins with "ro.", this property is write-once
and cannot later be modified, e.g. in /system/etc/init.goldfish.sh.
In other words, you cannot use "emulator -prop ro.sf.lcd_density=<value>", since
it is impossible to override the value defined in build.prop
This patch modifies the system to recognize "qemu.sf.lcd_density" as an override
value, which can be set with "emulator -prop qemu.sf.lcd_density=<value>", forcing
a specific density.
A later patch will allow the emulator to automatically set this property depending
on AVD hardware configuration settings.
now, all destruction path, go through the purgatory which is emptied when ~ISurface is called, but we also make sure to remove the surface from the current list from there (in case a client forgot to request the destruction explicitely).
Merge commit 'b61ae351256518add7bcb40e0bf18337dd87195c'
* commit 'b61ae351256518add7bcb40e0bf18337dd87195c':
log the geomerty of surfaces causing an out of memory in SurfaceFlinger.
