summaryrefslogtreecommitdiffstats
path: root/libs/hwui/thread
Commit message (Collapse)AuthorAgeFilesLines
* Restrict number of hwuiTask threadsJohn Reck2015-07-071-1/+3
| | | | | Bug: 22324907 Change-Id: I0013557ede15949a5bd6f3f75bc5dd023a9f945b
* Simplify TaskManager fallback pathChris Craik2015-04-201-4/+12
| | | | Change-Id: Ie3833449f7fe6aa69b9f71eb8bab1bef0fe434aa
* Shave another 10us off of hwuitaskJohn Reck2015-03-241-2/+4
| | | | | | | | | | | | | pthread_cond_signal does not need the mutex to be held to signal. This results in the thread waking up trying to grab the lock, failing, the signaling thread to wake up, release the lock, immediately get preempted for the signaled thread which can now proceed. Release the mutex before signaling to avoid the ping-pong scheduling issue, which shaves another 10us off of this Change-Id: Ie6bccca031ba6528f357eae8352b74626a6318c7
* Shave 10us off of hwuitaskJohn Reck2015-03-241-2/+5
| | | | | | | | | | | 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
* resolved conflicts for merge of c7e6b93a to masterJohn Reck2015-02-042-10/+4
|\ | | | | | | Change-Id: I4b791f37193727a0306214645f2f98cdf218cad0
| * Merge "Fix ANR caused by hwuiTask thread"John Reck2015-02-042-10/+4
| |\
| | * Fix ANR caused by hwuiTask threadSangkyu Lee2015-01-122-10/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | am f7049289: am 3812e68e: Merge "kill HAVE_PTHREADS."Yabin Cui2015-01-271-5/+1
|\ \ \ | |/ / | | | | | | | | | | | | | | | automerge: 3a10a67 * commit '3a10a672f05735be46256617b8a61cdb1e589008': kill HAVE_PTHREADS.
| * | kill HAVE_PTHREADS.Yabin Cui2015-01-261-5/+1
| |/ | | | | | | | | Bug: 19083585 Change-Id: Ib466949bb6cd6d1bbc4680e989f0f9fae62ca564
* | Add overrides and switch to nullptr keywordChris Craik2014-12-222-3/+3
|/ | | | | | | | Changes generated with clang-modernize. Additionally, fixed some struct-vs-class usage to make clang happy. Change-Id: Ic6ef2427401ff1e794d26f21f7b44868fc75fb72
* Fix hwuitask & RT prioritiesJohn Reck2014-08-152-0/+11
| | | | | | Bug: 15993695 Change-Id: Ib6f07237cb834e8d10f3074f8fb206d27f91859a
* Clean up tessellation cache in prep for other tesselation typesChris Craik2014-06-181-3/+1
| | | | | | | | bug:15536396 Also fixes compilation warning, avoids SkPaint deep copy Change-Id: I74334f08b1d34c6789aabf968ff62db5bacbed1b
* Tessellate on worker threadsChris Craik2014-06-101-2/+4
| | | | | | Tessellate and cache (where possible) shadow and round rect tessellation tasks. Change-Id: I2cfda8e11d83d51ea74af871235cf26e8f831d40
* Properly account for created paths in the cacheRomain Guy2013-08-211-1/+1
| | | | Change-Id: I47b89b3085cefab6daac9194e7bfd3c140b37fa2
* Add an on-screen overdraw counterRomain Guy2013-05-031-1/+1
| | | | | | | | | The counter can be enabled by setting the system property called debug.hwui.overdraw to the string "count". If the string is set to "show", overdraw will be highlighted on screen instead of printing out a simple counter. Change-Id: I9a9c970d54bffab43138bbb7682f6c04bc2c40bd
* Stop worker threads on memory trim & fix bad pointer accessRomain Guy2013-03-202-0/+12
| | | | Change-Id: I6fe7e31aeb6dd41fa65ab952caed97bc2da510d7
* Add TaskManager APIRomain Guy2013-03-125-1/+354
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Precache paths from a worker threadRomain Guy2013-03-113-0/+172
Change-Id: I3e7b53d67e0e03e403beaf55c39350ead7f1e309
generated by cgit v1.1 at 2024-07-01 22:14:43 +0000