This change dedupes the various properties that were represented both
in TransformationInfo, and RenderProperties on the native side.
RenderNode (and its associated properties) are now permanently
attached to a View in SW or HW. The native copy of these properties
are their sole representation.
Alpha to come in a later CL.
Also fixed issue with copying RenderNode's transform, and added
support of deleting RenderNodes in software rendering.
Change-Id: Ideb6e7f32b780e87aa1c32637c368356b3eee3a1
The method is in libhwui.so but used by libandroid_runtime.so
(via android_view_GLES20Canvas.cpp). If the compiler decides not to
inline this method, the linker won't be able to resolve the dependency
when it has hidden visibility.
The problem is found when testing GCC 4.9.
Change-Id: I3b4d096c7767f0bef0796886dfb2c5ba2ecff48c
bug:13211941
Cleans up some of the RenderNode method naming
Also removes unnecessary clip/save/restores, clipping shadows
predictably, as drawn by the parent, before drawing (and clipping,
etc.) the shadow casting child.
Change-Id: I795115e1fb869bbbdd7be43e279b97490fecc7e0
Changes in this patch include
[x] Use %zu for size_t, %zd for ssize_t
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
Change-Id: Id1aaa7894a7d0b85ac7ecd7b2bfd8cc40374261f
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Bug: 13635394
mDisplayListData can be null, make sure
to check for that before trying to walk through the
children list in updateProperties
Change-Id: I8d97b1656c1acf47b7c5df8a8771b0f30907261d
A Patch can be fairly large, holding bitmap data, but
is also frequently leaked which adds to the severity.
The feature is used in many important processes such
as Home, SystemUI and Chrome.
The following leaks are solved:
1. The Patch itself was not always freed.
PatchCache::removeDeferred() can mark patches to be
cared for by PatchCache::clearGarbage(). But
mCache.remove() would only destroy the container
and the pointer, not the Patch object itself.
2. The vertices stored in the Patch at Patch::createMesh()
would always leak. The empty/default destructor in Patch
would not properly destroy "vertices" since it's just a
pointer.
3. A BufferBlock that's added to the mFreeBlocks
in PatchCache could leak. The leak happened when a
patch later needed the entire free block, because the
object was removed from the list but never deleted
in PatchCache::setupMesh().
Change-Id: I41e60824479230b67426fc546d3dbff294c8891f
All the computations are estimated using bounding box.
TODO: Spot shadow could have more accurate but also more expensive methods, we need
more experiments to decide.
Change-Id: I9c10c419576cee55daf0f9f278b0db78cb847447
bug:13214038
Because the caching of projection matrix didn't account for changes in
the offset flag, the flag could be ignored. Now we use both to verify
that the cached matrix can be used.
Change-Id: I193b94eaf0b98f046a6484f0866c3d25048653fd
(cherry picked from commit d04a6b15f74035fd2068f34225825b55e94521f4)
In the current design, this error should be tolerated since the delta should
be small enough. So we should not return here.
Change-Id: I251db2882b331d37ae7f0896e9aa95d69a5650da
