PerformanceHintManager.Session is in java, so add JNI and a HintSessionWrapper
class in HardwareRenderer. Then pass the two calls as two std::functions
into DrawFrameTask.
Note Session is created per HardwareRenderer, not global (per
RenderThread).
Session includes UI thread, render thread, and the thread pool.
Desired duration is from the intended start duration to the frame
deadline. Add an actual frame start time to compute
Add system properties:
debug.hwui.use_hint_manager to enable PerformanceHintManager
debug.hwui.target_cpu_time_percent to control percentage of frame time
to be used for target cpu duration.
Test: Manual test that there are no crashes and values make sense.
Bug: 158791282
Change-Id: I83f25433c10daa20033803fb7c4ae45eab34f1d3
Using SYSTEM_TIME_MONOTONIC works for Android (where it translates to
CLOCK_MONOTONIC) and host targets, while CLOCK_MONOTONIC is not defined
on macOS.
Bug: 117921091
Test: existing tests should pass
Change-Id: I1fad472881830fb0701a320cf37319e083932ad4
This reverts commit 162305aaceca5f6cbaa03db1aa124f67e313612e.
Adjusted tests to ensure they pass on cf_x86
Bug: 129250875
Test: this on cf_x86 & blueline
Change-Id: Ic3245ec8db784ae356b7fa66dda9a2fc91c622ea
This reverts commit 5ff61f32a78dca0c722c8ac2685874a26190ceed.
Reason for revert: causes global presubmit to be very flaky, see b/130081457
Fixes: b/130081457
Change-Id: I93aa5d6686cd6b5bf831766c9e47c291749526a9
Replace it with a newer, fancier, WorkQueue-inspired
one that's just a global common thread pool.
Test: hwuiunit passes
Change-Id: Ib5d03104a08bbac9a4ec67a1bfc0db2b35d6700f
Unlike the Java Looper the native one requires manually
setting of the looper for a particular thread.
So... do that.
Fixes: 124467483
Test: really good guess
Change-Id: Iac9b4a052e79228aea5760262996729d8dadb1b8
RenderThread is setup as a daemon thread, which allows JVM to
exit without waiting on it. This CL does same setup for HWUI
worker threads, which offload work from the RenderThread.
This fixes an issue exposed by Vulkan pipeline, which is pushing
different loads to the worker threads and causing some java tests
to hang on exit. This is not a Vulkan specific issue, because GL
also hangs if worker thread is started.
Bug: 123374538
Test: Ran DismissDialogsInstrumentation test
Change-Id: Ie4ee94737ced975323a0792f57f8426c958e8056
When closing a namespace a } is sufficient. It doesn't need to be };
like closing a class or enum.
Within frameworks/base/libs/hwui there is a mix between } and }; when
closing a namespace. There are even mixes between a .h and the
corresponding .cpp files.
In a separate CL I was asked to not close with };. That was a good
comment. I adopted the style from nearby code. This CL cleans up the
nearby code.
Test: I made sure the code still built as expected.
Change-Id: Ieb314a4f48d6e33752463f3be4361fdc9be97482
* Add explicit keyword to conversion constructors.
Bug: 28341362
* Use const reference type for read-only parameters.
Bug: 30407689
Test: build with WITH_TIDY=1
Change-Id: Iab3e6636f60a70cb124f29dc19f20f842fa8dfda
Bug: 28519669
This trace tag makes shadows look way more expensive
than they actually are, particularly troublesome
when tracing things with large number of shadows.
Change-Id: Ib6558b1388edd4b006ec15127470cb9ab563f954
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
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
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
Changes generated with clang-modernize.
Additionally, fixed some struct-vs-class usage to make clang happy.
Change-Id: Ic6ef2427401ff1e794d26f21f7b44868fc75fb72
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
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
