bug:17478770
This removes a lot of redundant property query code, and puts the
queries all in one place, so defining them automatically will be simpler
in the future.
Change-Id: I0428550e6081f07bc6554ffdf73b22284325abb8
When precache, PathTexture is added to PathCache, and it is released after drawn if we want to clean it.
But the PathCache LRU still holds the entry of the PathTexture object. When trim the cache in
the end of each frame, LRU finds that its mListener is not NULL and invoke the functor, however,
mListerer points to the released PathTexture object and is a dangling pointer, thus leads to crash.
Smart pointer don't help here since they only manage scopes, while PathTexture is also controled by
its cleanup field.
The fix is to also remove the LRU entry of PathTexture*, it will also release the texture object
and there won't be texture leaks.
Change-Id: Iaa0621df5dc71532e9e75b38ad94384353930b95
bug:19967854
Separate properties from Caches, into static, RenderThread-only class.
Also rewrites the means for java to set properties to correctly handle
threading, and adds an override for profile bars so that SysUi doesn't clutter
the screen with them.
Change-Id: I6e21a96065f52b9ecc49d1a126244804ba106fa9
This removes dependence on SkPath ptrs that HWUI does not control
the lifecycle of. This clears up some errors where the paths are
not generated from Java, but rather the Skia test suites.
Cherry-pick of a change that originally landed in master-skia and is
dependent on a skia merge (ag/655422).
Change-Id: I41b9797a2b0af5d6b4ea51891565469d4f1d832d
If hwuiTask thread is exited while HWUI renders something,
some tasks can remain unfinished forever.
This can make ANR problem if RenderThread waits this kind of tasks.
According to the current implementation, hwuiTask threads are
exited when HWUI receives trimMemory() callback with level >= 20
and some applications such as SystemUI can receive trimMemory()
with level >= 20 even though they renders something yet.
(For instance, when RecentsActivity in SystemUI is finished,
HWUI receives trimMemory() callback with level >= 20
but SystemUI should still render the status bar and navigation bar.)
This patch prevents the tasks from remaining unfinished and
make the tasks executed immediately if they cannot be added
to their TaskProcessors.
Change-Id: I5bd26439aa5f183b1a7c1ce466362e27554b4d16
Adds remaining missing overrides and nullptr usages, missed due to
an extreme failure in tool usage.
Change-Id: I56abd72975a3999ad13330003c348db40f59aebf
Remove Clang cutout for unused parameters. Fix warnings.
Remove Clang cutout for deprecated Skia function usage. Has been
fixed in the L push.
Change-Id: I7ea073ff67127cc1e14e798b655e2c50615fe8e7
bug:17702227
Add details useful to developers (such as layer size/View name), and
switch away from logging implementation names/details, since they
are generally not relevant to developers.
Change-Id: Iee605d182f241450f7e75a6d0c283d51fa1312f5
When enabled defer rendering, it will do precache for DrawPathOp.
The paint used for creating PathTask in precache just get the address
of mFilteredPaint of OpenGLRenderer. So for the following defer
operation like DrawTextOp has possibility change the mFilteredPaint
by getPaint while another WorkerThread in PathCache is using the paint
which pointed to the same address of mFilteredPaint to generate bitmap.
As a result, it will generate a wrong bitmap for generateTexture in
PathCache. To fix it, do a copy of paint when creating PathTask.
CRs-Fixed: 664244
Change-Id: I5516f5b143458b88d3573d15b7ebb34f688800c7
Some caches(PatchCache, TextureCache, PathCache) for HWUI
uses deferred removal for their cache entries even though
actual resource objects are immediately freed by
ResourceCache.
For this reason, the uniqueness of a resource address in
the caches is not guaranteed in specific cases.
(Because malloc() can return the same address when malloc()
and free() called very frequently.)
So it can be possible the cache have two cache entries for
two different resources but the same memory address.
(Of course one of the resources is already freed.)
It also can be possible mGarbage vector in PatchCache has
duplicated addresses and this can lead to duplicated free
blocks in the free block list and graphics corruption.
(Deferred removal was implmeneted based on an assumption of
unique resource addresses.)
So this patch makes sure resource objects are freed after
the resources are removed from the caches to guarantee
the uniqueness of a resource address and prevent graphics
corruption.
Change-Id: I040f033a4fc783d2c4bc04b113589657c36fb15b
Signed-off-by: Sangkyu Lee <sk82.lee@lge.com>
This change adds refcounting of Res_png_9patch instances, the native
data structure used to represent 9-patches. The Dalvik NinePatch class
now holds a native pointer instead of a Dalvik byte[]. This pointer
is used whenever we need to draw the 9-patch (software or hardware.)
Since we are now tracking garbage collection of NinePatch objects
libhwui's PatchCache must keep a list of free blocks in the VBO
used to store the meshes.
This change also removes unnecessary instances tracking from
GLES20DisplayList. Bitmaps and 9-patches are refcounted at the
native level and do not need to be tracked by the Dalvik layer.
Change-Id: Ib8682d573a538aaf1945f8ec5a9bd5da5d16f74b
Bug #9316260
The GL specification indicates that deleting a bound texture has
the side effect of binding the default texture (name=0). This change
replaces all calls to glDeleteTextures() by Caches::deleteTexture()
to properly keep track of texture bindings.
Change-Id: Ifbc60ef433e0f9776a668dd5bd5f0adbc65a77a0
This change will greatly simplify the multi-threading of all
shape types.
This change also uses PathTessellator to render convex paths.
Change-Id: I4e65bc95c9d24ecae2183b72204de5c2dfb6ada4
This API can be used to run arbitrary tasks on a pool of worker
threads. The number of threads is calculated based on the number
of CPU cores available.
The API is made of 3 classes:
TaskManager
Creates and manages the worker threads.
Task
Describes the work to be done and the type of the output.
A task contains a future used to wait for the worker thread
to be done computing the result of the task.
TaskProcessor
The processor dispatches tasks to the TaskManager and is
responsible for performing the computation required by
each task. A processor will only be asked to process tasks
sent to the manager through the processor.
A typical use case:
class MyTask: Task<MyType>
class MyProcessor: TaskProcessor<MyType>
TaskManager m = new TaskManager();
MyProcessor p = new MyProcessor(m);
MyTask t = new MyTask();
p.add(t);
// Waits until the result is available
MyType result = t->getResult();
Change-Id: I1fe845ba4c49bb0e1b0627ab147f9a861c8e0749
