composeLayerRect() pays attention to the offset of the layer, but
composeLayerRegion() ignores it. This patch makes the behavior of
the region case match the behavior of the rect case.
The difference will only be shown by tests which do not position
the saved layer at the origin.
BUG=20288561
R=ccraik@google.com,djsollen@google.com
Change-Id: Ie22737a8614c508cbffe39aa4c55f7d5434277aa
Switch a few places to using android::canvas
instead of SkCanvas as well which eliminated
some JNI
Change-Id: I8f98b56442a06362b82b984cd1bd3a92398d8dbc
Canvas drawText* APIs are inconsistent, and this mismatch snuck through
our tests.
BUG=skia:3636
R=djsollen@google.com
Change-Id: Ibaab512c3f19df8445d582633b2748f1ec4d2902
Also tune the parameters to match a better look designed by UX team.
For ambient part, the acos transformed alpha is not needed any more.
b/19370798
Change-Id: I20d2615d1be502eb900942ed756aecd1660dee48
Was here because UBsan found integer overflow in the parsing for hex
numbers, since hex numbers here are actually unsigned but assigned to
a signed integer.
Also fixes a number of missing error conditions.
Change-Id: Iaea576daedfc6c75521cde02de3fe9dd0198a3b7
Add CLOCK_MONOTONIC to signal
when the stat collection started
to allow for tracking stats
over time
Change-Id: Iab7c52f21184eea603ddc8572b9d91a951b45a00
ClipArea's region mode implementation store the region's boundary in
a rectangle, and if the region is that rectangle, set its region to
empty. This is a bug, since as long as the ClipArea is in region
mode it treats its region as determinitive. When the next clipping
operation comes in, it is tested against the empty region instead of
against the valid rect.
Discovered via Skia GM testing.
Change-Id: I3bbc4e81c8d68636061f830156e017e9b5c7e587
More S's for More Speed
Split JankTracker's backing data from the
class to allow for data relocation to/from ashmem regions
Pack the jank tracking data to fit in 256 bytes
Change-Id: Ife86a64b71a328fbd0c8075fe6a0404e081f725b
We now peform a total-size preflight pass before committing data to the
wire. This is to eliminate the large superfluous network traffic that
would otherwise happen if the transport enforces internal quotas: we
now instead ask the transport up front whether it's prepared to accept
a given payload size for the package.
From the app's perspective this preflight operation is indistinguishable
from a full-data backup pass. If the app has provided its own full-data
handling in a subclassed backup agent, their usual file-providing code
path will be executed. However, the files named for backup during this
pass are not opened and read; just measured for their total size. As
far as component lifecycles, this measurement pass is simply another
call to the agent, immediately after it is bound, with identical
timeout semantics to the existing full-data backup invocation.
Once the app's file set has been measured the preflight operation
invokes a new method on BackupTransport, called checkFullBackupSize().
This method is called after performFullBackup() (which applies any
overall whitelist/blacklist policy) but before any data is delivered
to the transport via sendBackupData(). The return code from
checkFullBackupSize() is similar to the other transport methods:
TRANSPORT_OK to permit the full backup to proceed; or
TRANSPORT_REJECT_PACKAGE to indicate that the requested payload is
unacceptable; or TRANSPORT_ERROR to report a more serious overall
transport-level problem that prevents a full-data backup operation
from occurring right now.
The estimated payload currently does not include the size of the
source-package metadata (technically, the manifest entry in its
archive payload) or the size of any widget metadata associated with
the package's install. In practice this means the preflighted size
underestimates by 3 to 5 KB. In addition, the preflight API currently
cannot distinguish between payload sizes larger than 2 gigabytes;
any payload estimate larger than that is passed as Integer.MAX_VALUE
to the checkFullBackupSize() query.
Bug 19846750
Change-Id: I44498201e2d4b07482dcb3ca8fa6935dddc467ca
