Bug: 14052927
destroyCanvasAndSurface() needs a fence as when it returns the
underlying BufferQueue is going to be released from under
the render thread.
Change-Id: I0147a1d5ec5adf0239c761ef22f65cd8c8a137df
bug:9321162
mDestroyed is no longer useful, as RenderNode is ref counted (not to
mention having its lifecycle significantly redesigned).
Change-Id: I429b9dd7740362c85d6416fbae567f0d47098e4e
Bug: 13952590
It was attempting to flush state changes after the canvas was
destroyed, which caused layer updates to crash.
Due to the removal of SetDisplayListData, the sync mode isn't able
to do anything ever, so remove it.
Change-Id: I1e18ce288d81fd47cc6e612afda9476f75ecef2e
Bug: 13914116
Fixes lifecycle issues around setEnabled where ThreadedRenderer
was reporting as being enabled before it had a Surface. This is
incorrect.
Also fix some EGL lifecycle issues
Change-Id: I12ebb279707f9b533a570b61d68735d858b560bf
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
