The build system takes care of linking the correct STL and gtest
libraries for you, and specifying them manually confuses the build
system when using libc++.
Change-Id: I9f76ab26a63ace51293614cfb5ca002f37438e02
Fix the valid umbra detection.
This looks better b/c every vertex will have one ray shooting at it, such that
we don't miss the corner.
This performs better too, due to the polygon intersection is removed and less ray
intersection. 2x performance for rect and circle for spot shadow in test app.
b/17288227
b/15598793
b/16712006
Change-Id: I4a5ee397b9e192e93c8e35e6260b499e3e38a6f4
bug:17441218
GLConsumer uses glBindTexture() directly instead of going through
Caches::bindTexture(). This can cause libhwui to draw with the wrong
texture bound in the following case which involves 2 TextureViews:
Frame 1:
GLConsumer::updateTexImage() calls glBindTexture(GL_TEXTURE_EXTERNAL_OES, 1)
HWUI renders TextureView A:
calls Caches::bindTexture(GL_TEXTURE_EXTERNAL_OES, 1) and draws
Frame 2:
GLConsumer::updateTexImage() calls glBindTexture(GL_TEXTURE_EXTERNAL_OES, 1)
GLConsumer::updateTexImage() calls glBindTexture(GL_TEXTURE_EXTERNAL_OES, 2)
HWUI renders TextureView A:
calls Caches::bindTexture(GL_TEXTURE_EXTERNAL_OES, 1) and draws
HWUI renders TextureView B:
calls Caches::bindTexture(GL_TEXTURE_EXTERNAL_OES, 2) and draws
In this case, HWUI will incorrectly draw TextureView A using texture 2 on
frame 2, because mBoundTextures[0]=1, even though the texture currently
bound to GL_TEXTURE_EXTERNAL_OES is 2.
Since GLConsumer is always used with a target of GL_TEXTURE_EXTERNAL_OES,
work around this problem by having mBoundTextures[] store only the
textures bound to the target GL_TEXTURE_2D. This is the common case
where the extra performance is needed. Since it's legal to have
different textures bound to GL_TEXTURE_2D and GL_TEXTURE_EXTERNAL_OES
on one texture unit, Caches::bindTexture() does not need to clear
mBoundTextures[mTextureUnit] when target != GL_TEXTURE_2D.
Change-Id: I8bc54ab8adcfacad7f3ed17a31236dc7a86c967a
Signed-off-by: Fred Fettinger <fred.fettinger@motorola.com>
bug:17401066
Now correctly accounts for scale, both in hairline case (where scale
needs to be accounted for), and in standard case (where scale
shouldn't be applied, since bounds are in local space)
Change-Id: I597a20834dce42ddb741b46e4c1a4f3169a48ccc
In C++11 mode, "foo"MACRO_THAT_EXPANDS_TO_STRING gets lexed as a user
defined literal. Add space around the macro.
Change-Id: I24fbe1fda483db4a8c606e80dbe17430ad070dc2
When compiling in C++ mode, the compiler will complain about conversions
from uint16_t to char16_t. Be consistent in using char16_t for strings.
Change-Id: I052b6176ced635162920b31560052d9a64f92764
bug:17208461
They are destroyed via finalizer-enqueued destroy method, so it's not
valid to check that they've been destroyed at gl context destruction
time.
Change-Id: I670f69825547facd5f31d44acb406418881fee00
Bug: 17317184
Unfortunately this will disable *all* RT animations in a scene,
but we don't have more selective targetting currently
Change-Id: I57e1c0ae43957f45229473bdcdaf34c05825fab7
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:15780987
bug:17350602
Also update docs around clipping nesting behavior,
and some Z ordering behavior.
Change-Id: Iaa204350a0adfdcbd8c4b821fb4a9c0ae22f2613
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
