* Move HintSessionWrapper into its own file
* Refactor HintSessionWrapper initialization and lifecycle
* Move HintSessionWrapper instance into CanvasContext
* Have HintSessionWrapper do its own validity checks
* Have HintSessionWrapper implicitly initialize when called
Bug: b/260267128
Bug: b/260224719
Test: manual
Change-Id: I69f89bb5ef601d1b5d9fca1a5da62256f2556da8
Send a load reset hint hint to DrawFrameTask through ThreadedRenderer
from ViewRootImpl whenever Choreographer registers a callback. This
allows the PowerHAL to allocate more resources for HWUI in response to
upcoming work, helping prevent frame drop.
Bug: b/243938267
Test: manual
Change-Id: Ie2cf809cf85530af04f4d0db3407853d4da03d62
Should be a mostly no-op but adds a handful of new options
* Adds a 'MemoryPolicy' to mostly consolidate memory settings
* Moves trim handling into HWUI proper
* Adds settings for UI hidden & context destruction that's not
dependent on TRIM signals
* Treats persistent process the same as system_server
* Tweaks HardwareBitmapUploader timeout to reduce churn
Bug: 245565051
Test: builds & boots
Change-Id: I1f1b3db884ef7fa45ff2556436464a99440b998e
Also make it actually async, and allow the bitmap
to be auto-allocated
Bug: 195673633
Test: PixelCopyTest CTS suite
Change-Id: Ie872f20c809eaaeb8dc32f3ec6347f21a9a7bc1a
The forceDraw flag in HardwareRenderer will ensure a frame is drawn when
requested even if it would end up drawing multiple frames in a single
vsync.
This is to help blast sync when we want to synchronize the
buffer. We want to make sure we are guaranteed a callback since we don't
want to wait for retries, especially in the case when trying to synchronize
multiple buffers.
There was already a global flag to handle this, but would use the flag
for all draws. This new function is set per draw so once a frame is
drawn it's unset. The global flag was only used for tests so updated the
test to set the flag before every draw and deleted the global property.
Test: Underlying code was in place. This is just piping a new setter. No
usages yet.
Test: TestSceneRunner
Bug: 200284684
Change-Id: Ie1c9950cabb7331cfed1721564a51a1a15cd1624
HWUI already supports disabling RT animations, but there was no correct
way to call it from the application. Adding a call to enable or disable
RT animations on the RenderThread so RT animations can be disabled
during a blast sync.
Test: Builds
Bug: 200284684
Change-Id: Ia1ae3498c38b84b4975f08d37bc764f0c690ed9f
In https://skia-review.googlesource.com/c/skia/+/512416,
we would like to decouple SkImage and SkImageEncoder. This CL
was created by searching for use of these objects:
- SkEncodedImageFormat
- SkStream
- SkData
- SkBitmap
- SkPixmap
and making sure those files followed the Include What You Use
(IWYU) guidelines.
Signed-off-by: Kevin Lubick <kjlubick@google.com>
Change-Id: I8edbcd1c9a526b8084d7e2c023895d1ad2f8c9b1
FrameCallback sends back the syncStatus and allows the caller to return
a FrameCommitCallback. This is so the caller can evaluate the results of
the sync and determine if it wants to continue waiting for a commit
callback. In cases, where the sync has failed, there will never be a
commit callback so the caller can avoid waiting.
This is partically helpful for VRI because it wants to sync with a frame
that will draw, but also doesn't want to get stuck indefinitely waiting
on the callback. VRI can check the syncStatus and only handle blast sync
and/or reportDraw when its determined that a draw will happen.
This allows VRI to remove frameCompleteCallback since it can now wait
until a buffer has drawn instead of when the vsync has completed. This makes
sure it waits on FrameDropped since that result indicates HWUI will draw on
the next vsync
Test: BlastSync
Bug: 200284684
Change-Id: Ic6e2f08ea21ac8a1634a3389c927fcb68ede3f7b
The previous code waited for a frame complete callback from hwui before
notifying WMS that a draw had occurred. However, frame complete callback
was not guaranteed to get called since it only invokes a callback if a
draw actually occured. VRI really needs a signal that RT has completed,
since it just needs to know that a draw was possible so it can notify
WMS that the RT completed its pass.
Instead, rename frameCompleteCallback to frameCommitCallback since that
API is exposed to a public API when a frame was actually drawn.
Create a new callback, frameCompleteCallback, that is invoked when the
draw has completed, regardless if a frame was actually drawn.
When the frameCompleteCallback is invoked, VRI can check to see if a new
frame actually drew. VRI can call into BBQ to see if the frame acquired
matches the frame that was attempted to draw. If so, VRI can wait on a
transaction callback. If not, it can allow VRI to continue. In either case,
it will notify WMS that the draw has finished.
Test: Split over and over
Bug: 195262673
Change-Id: I24dd19ab2746be3fc33e597761abf8c5249f8b5b
This reverts commit da35596834.
Bug: b/192050906
If too many RenderProxies are destroyed too quickly, we can end up jamming up the CommonPool preventing RenderThread from making progress if it's waiting on CommonPool tasks.
Change-Id: I8c324bc60891440d9b7be67961f8d5f881dc0f03
Speculation for the cause of an ANR. HardwareRenderer's
cleaner can block on RenderThread, which in turn blocks ART's
cleaner thread. This can potentially cause other blockages, but
it's also poor behavior to have such a long-running Cleaner anyway.
Avoid this by putting cleanup to CommonPool.
Bug: 191514384
Test: make, CtsUiRenderingTestCases still passes
Change-Id: I8190f7862528c3ac39ce636f6fca229322480968
A native transaction passed from webview is sent back to native side, so java side does not manage the life cycle of the transaction.
Bug: 191414767
Test: Play a video, switch to another app, wait for 10 seconds
Change-Id: I013052c202b445438d6cb6497f5f9a2fc22a2b85
Set the root surface control transparent, and set the z order of the newly created child surface control to -1.
A new callback is needed to update root surface control in sync from Java side.
Bug: 186750329
Test: use latest APKs from Webview team, play a video, mini toolbar should be visible
Change-Id: I0b37ee8f83fd2b41ff4f2856dbadd31ff6170baf
Add support for glob matching
Ensure glob matches are alphabetically sorted
Add feature to dump GPU memory usage after a test pass
Adjust gpu memory dump to be a bit more compact (skip empty outputs)
Test: this
Bug: 187718492
Change-Id: I6dc80b2d3379d8d10001116e1240727d9914bc10
The basic idea is to create a child surface control from the root surface control passed from ViewRootImpl to the render thread.
Transactions are sent back to the java layer to get merged.
In case of offscreen layers, SurfaceControl must be disabled.
This new feature is disabled for Vulkan at the moment, a new CL will be used to enable the support.
Bug: 173671170
Test: manual, webview apks
Change-Id: I119405d13eca3c59fd3ec78e50dc7739f78411d4
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
- Add SurfaceStatsCallback to TransactionCompletedListener
- Register a callback in RenderProxy to be called when we have
surface stats from SF via the BLAST callback.
- Instead of finishing a frame for frame metrics reporting
immediately, wait until BLAST callback fires, note GPU completion
time and finish frame.
- Expose GPU_COMPLETION in FrameMetrics
- Modify TOTAL_DURATION to also include GPU_COMPLETION
Test: FrameMetricsListenerTest
Fixes: 171046219
Change-Id: I16fa1d80cfc4e7a5527c18fec7e885409f17ee4d
add a method, setSurfaceControl, for java layer to pass surface control to the render thread
Bug: 173671170
Test: call setSurfaceControl method in ViewRootImpl.java
Change-Id: I886a79c377938f19cf38b9058f2bec64e1439000
As HWUI uses vsync id to send buffers to SF, SF applies the right
amount of render ahead by latching the buffers at the configured time.
Test: launch an app and observe systrace
Bug: 178148035
Change-Id: Ifd3e1a2971aad0a085cb35d33e950194046aa634
ANativeWindow usage now has enough feature parity so that we can use
that instead.
Bug: 137012798
Test: builds
Test: Scroll through settings
Change-Id: I0054315058b28bcb5e779a6f71a3cfb164625a5f
By avoiding setting a dequeue buffer timeout we avoid
hitting a different path in BufferQueue that prevents
async behavior from happening. This restores P's
behavior in this path.
Bug: 143860379
Test: repro app in bug
Change-Id: Iffbd9f9e6689a40876ff3aa74c10020e3f09fc6a
Poking around in a few apps it doesn't appear that
the VectorDrawableAtlas is achieving sufficient
utilization to justify its existence. The potential for
draw call merging doesn't seem warranted for the
RAM cost of the atlas.
Bug: 137853925
Test: builds
Change-Id: Id2419bc6dccb6316636d50c568f8fac75a2d563f
GraphicsJNI.h will only be visible to files in the graphics component
and this CL begins to remove all usages of that header that are known
to be outside the graphic component.
Test: compile
Bug: 137655431
Change-Id: If310782e5d95d05ab7cbd54dafa5771d315707a7
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
Currently only supported in the EGL path.
Vulkan support Coming Soon
Bug: 127822449
Test: trace of hwuimacro
Change-Id: Iac2b039e11d964aab5b8ca1bdf2a5430b187e2ea
Replace it with a newer, fancier, WorkQueue-inspired
one that's just a global common thread pool.
Test: hwuiunit passes
Change-Id: Ib5d03104a08bbac9a4ec67a1bfc0db2b35d6700f
This CL should fix application startup regression for Vulkan
detected by "Hermetic Startup: EmptyActivity" test.
EGL drivers are loaded in a temp thread to leave more time
in RenderThread for other work. Loading EGL drivers
on the RenderThread may cause a perf regression.
Test: Ran cold-dropcache-test test.
Bug: 122659224
Bug: 123361175
Change-Id: I8ca818e98fac196a41d079be15594caca5cb1bab
