summaryrefslogtreecommitdiff
path: root/libs/hwui/thread/TaskManager.cpp
AgeCommit message (Collapse)Author
2016-02-05Revert "TaskManager bench"Daniel Chapin
This reverts commit 02db03ca0584371504fd29ced77c00d601cb0971. Change-Id: I86bdf5e6774e99f9add59a657bfc50d45ebfda1d
2016-02-04TaskManager benchChris Craik
bug:26964750 Change-Id: Ibda0cd2e5e64331a4367d4985d6acfd6f3baeda1
2015-07-30Replace most usages of utils/Vector.hJohn Reck
Change-Id: I540d1b3523244d6c71fc52d6fb30555271c25644
2015-07-07Restrict number of hwuiTask threadsJohn Reck
Bug: 22324907 Change-Id: I0013557ede15949a5bd6f3f75bc5dd023a9f945b
2015-03-24Shave 10us off of hwuitaskJohn Reck
This prevents an issue where if the signal schedules hwuiTask it will immediately block and go back to sleep due to mLock still being held. This costs 10us in thread scheduling ping-ponging bouncing between hwuiTask and RenderThread Change-Id: I47595c1bf5736576483a6aa7aada0b1be1e04268
2015-02-04Merge "Fix ANR caused by hwuiTask thread"John Reck
2015-01-26kill HAVE_PTHREADS.Yabin Cui
Bug: 19083585 Change-Id: Ib466949bb6cd6d1bbc4680e989f0f9fae62ca564
2015-01-12Fix ANR caused by hwuiTask threadSangkyu Lee
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
2014-08-15Fix hwuitask & RT prioritiesJohn Reck
Bug: 15993695 Change-Id: Ib6f07237cb834e8d10f3074f8fb206d27f91859a
2014-06-10Tessellate on worker threadsChris Craik
Tessellate and cache (where possible) shadow and round rect tessellation tasks. Change-Id: I2cfda8e11d83d51ea74af871235cf26e8f831d40
2013-08-21Properly account for created paths in the cacheRomain Guy
Change-Id: I47b89b3085cefab6daac9194e7bfd3c140b37fa2
2013-03-20Stop worker threads on memory trim & fix bad pointer accessRomain Guy
Change-Id: I6fe7e31aeb6dd41fa65ab952caed97bc2da510d7
2013-03-12Add TaskManager APIRomain Guy
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