This code should not be triggered with scale == 1.0f because of the
density comparisons above though.
Change-Id: I9e39e3769a3b6550c97df3b213457947ec1f554b
Change-Id: I662159a086a56e28732dd64a3a3cb30f8d4b72b1
Replace lockless fifo from server to client with sockets.
Change-Id: I99a4ab4f18496c0fbac96ee7b8099797af4712ea
BUG=5955072
We used to call delete, which did not update the Context's view of the world,
leading to potential segfaults on Context teardown. This change also enables
exceptions to be thrown when runtime errors are encountered.
Change-Id: If63578efff2d7dd03639da1049c1a5ebc69fde35
This change also updates the documentation to warn the user about which properties
require a call to mutate().
Change-Id: I84717068bf026669e3eef1ae92db665a964fe08a
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 '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 '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
