AnimationDrawable.setVisible(true, true) was not correctly recording
the fact that it had started the animation, so it was possible to call
start(0 immediately afterwards and have two animations running on the
drawable in parallel, resulting in incorrect frame ordering.
Issue #5782773
Change-Id: Ifc328f755a51d10ab76b84006d1999df03d2dca1
* commit 'e693fa3e184f7a49f9bf912a0dac057fb339b8a4':
Followup to a bug fix. Addtion of synchronized to the methods triggers an API change. Per council advice, pushing synch block into the function body.
* commit 'a962ef2993099e6c5db3809a7e829e43c8cf084a':
Followup to a bug fix. Addtion of synchronized to the methods triggers an API change. Per council advice, pushing synch block into the function body.
BUG=5609007
The underlying LLVM implementation for vector3 types does this implicitly. If
RS does not adjust its implementation, we will always be misaligned for any
subsequent data after a vector3 type. We previously inserted padding into the
reflected layers from llvm-rs-cc (hence the skip padding part of this change).
We can safely ignore the padding now that the Java/native code is updated to
use the expanded size. The compiler will also need modification to ensure that
we don't mistakenly skip over any end-of-struct padding.
Fixing the 3 component vector padding problem.
Change-Id: If68af42287deb8f4b28addcd19a9fa314656be44
Addtion of synchronized to the methods triggers an API change.
Per council advice, pushing synch block into the function body.
Change-Id: Iaa395d9720bce499259ab750fe97149715e9f271
* commit 'b14d771cf07479e3186a167a219fb2d42d8d4d30':
Fixing a race condition in RSSurfaceView. Bug 5601083 When destroy is called shortly after creation, RS tries to set a surface on a partially destroyed context.
* commit 'f579bb92c2032cd27aef72a1654c006933b22bbd':
Fixing a race condition in RSSurfaceView. Bug 5601083 When destroy is called shortly after creation, RS tries to set a surface on a partially destroyed context.
* Don't call context.getResources() redundantly when unnecessary;
similarly for Resources.getCompatibilityInfo()
* During bitmap creation, don't bother clearing to 0: it's unnecessary
because now that the raw bits are stored in a VM-side byte array, it
was cleared at initialization time. Also, don't use the sanity-
checking public entry point to erase to a color, because we know
that we're by definition in a "legal" path to erase to the initial
contents and don't need to incur the overhead of the (inappropriate)
sanity checking.
Change-Id: Idaca4d64fdecefd5d51337646ead32e1db510e02
When destroy is called shortly after creation, RS tries to set a surface on a partially destroyed context.
Change-Id: I7a382a701efde3264e5cd9b9a9b428ade5eb4a9a
Bug #5435653
saveLayer() can be extremely expensive on some GPU architectures. Avoiding
this call greatly improve the rendering performance of drawables with
strok + fill.
Change-Id: Ib414174ba05d5bad56d942b8e67ab784e7d60b9e
Some progress bars use AnimatedRotateDrawable, which suffered
from the same bug as AnimationDrawable (until a recent fix). The
code would not account for the left/top offset of the drawable in its view,
so it would rotate the drawable around the wrong center, causing it to
wobble and not get erased properly.
Change-Id: I3f34f797e595973d9eb1d952d92026c769c7ec0a
