| Age | Commit message (Collapse) | Author |
|---|
|
Test: No code changes, just ran through clang-format
Change-Id: Id23aa4ec7eebc0446fe3a30260f33e7fd455bb8c
|
|
Fixes: 29072773
By using computeFrameTime AnimationContext would
potentially end up modifying the latest vsync if
a very-slow frame was received from the UI thread.
This could potentially desync animations that were
RT & UI thread 'synchronized', but more significantly
it would confuse the swap chain which tries to only
draw one frame per vsync causing unneccessary frame
drops.
Change-Id: Ibd2ec3157ce32fee1eec8d56837c45a35e622895
|
|
Adds remaining missing overrides and nullptr usages, missed due to
an extreme failure in tool usage.
Change-Id: I56abd72975a3999ad13330003c348db40f59aebf
|
|
Reverted as hwui doesn't agree.
This reverts commit 8a902d9f24e83c87b054adb5836b4a5b8a257be9.
Change-Id: I109e7b02bee2921e2155ded6df36f52e6f574b5a
|
|
Remove Clang cutout for unused parameters. Fix warnings.
Remove Clang cutout for deprecated Skia function usage. Has been
fixed in the L push.
Change-Id: I7ea073ff67127cc1e14e798b655e2c50615fe8e7
|
|
Bug: 17372309
AnimationContext::startFrame() happens both with and without
the UI thread lock. Pass the TraversalMode into it so
that ThreadedRenderer's subclass can correctly decide
when it is safe to push over mPendingAnimatingRenderNodes, as doing
so outside of the lock is Very Bad.
Change-Id: Ife5dd3a2b46b0a207cd9234c159a674afdbf5efd
|
|
Bug: 17372309
Fixes a case where UI thread and RT thread both used the same method
which wasn't safe for either of them.
Adds additional assertions & logging in unusual circumstances to
try and track down where the issue is occuring from.
Change-Id: I93d31a6fd0c5927259b67bdf96a475944226eee6
|
|
Change-Id: I290491f559281c7b3d1d132495ea2fffcfaf4725
|
|
Bug: 17313962
Change-Id: I66b86d50b415f9aa33da23297f22e2cf7f96f565
|
|
Bug: 17228458
Change-Id: Id884a429a512f9cd2be0ed16dbd0f10e92b4440d
|