Add null pointer check to avoid system crash.
Meet the below crash log during some app operations then app exits.
F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x78
F DEBUG : Cause: null pointer dereference
F DEBUG : backtrace:
F DEBUG : #00 pc 0000000000323858 /system/lib64/libhwui.so
(android::uirenderer::DeferredLayerUpdater::apply()+40)
F DEBUG : #01 pc 0000000000323040 /system/lib64/libhwui.so
(_ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13
DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv$c1671e
787f244890c877724752face20+416)
Bug: b/243310920
Signed-off-by: Jessie Hao <juan.hao@nxp.com>
Change-Id: I77226be2bd235852675bb4f7a29589e360269b33
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
postAndWait() shows the duration that UI Thread waits for RenderThread.
The trace is helpful for perfetto parser to calculate the actual frame
drawing time from CPU resource perspective.
Bug: 224653682
Test: capture trace and check App UI Thread.
Change-Id: Ic3a11b60abb1fea8cc7b44ce6889ab1e3c2788fd
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
Ensure GrContext::submit() is always called after either
Bitmap#prepareToDraw() or if DrawFrameTask skipped drawing.
In either case texture uploads & deletions will be scheduled,
but without the submit they won't actually be performed. This
can end up running out of RAM.
Bug: 189393671
Test: manual test app
Change-Id: I57477c64457558487e9e5ec0a979ad9099a8cb2c
Subtract out time spent blocked in dequeueBuffer. Also subtract out any
time UI spents waiting on render thread while render thread is blocked
dequeueBuffer, though this calculation is fairly crude.
Test: Checked bouncyball returns reasonable-ish numbers even when HWUI
is ahead of surface flinger
Bug: 187556381
Change-Id: I368c446d93990ff8b7b645e30509405ba799c79c
- Use GPU finish time as well as actual deadline to determine jank
rate.
- Use dynamic interval to adjust for 60/90hz switching
- Move frame metrics reporting into JankTracker to adjust the
deadline communicated to the app when in stuffing scenario.
- Adjust double-stuffing detection to be a bit more readable.
Test: GraphicsStatsValidationTest.java
Test: adb shell dumpsys gfxinfo
Test: FrameMetricsListenerTest
Test: Log output of FrameMetricsObserver
Bug: 169858044
Change-Id: I3a6b8ed163e2cf9cf2b67667110340ebe35f98a1
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
Pass the frame deadline calculated by SF to Choreographer so
hwui would be able to improve its stats by knowing if a frame is
likely to be late.
Bug: 169858174
Test: manual
Change-Id: Ib9fd93638b54f08d8dc72fa6b023e2dd7c276dc7
Add plumbing to get shared timeline data from Surface Flinger to HWUI
and back.
Bug: 162890382
Bug: 162888881
Bug: 162890407
Test: manual using ALOG messages in SF
Change-Id: I85c5eb56d2fa933889518854e7b79b1e65e29af3
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
Otherwise it could lead to parameters applied in the wrong frame,
leading to jank.
Test: Open notification
Bug: 78611607
Change-Id: Ia7900e753b29187a7a7b81f393666687e8b8e04b
For periods of time during which latency is less important
allow a client to request a deeper render-ahead pipeline.
The latency tradeoff results in less overall visual jank
Test: none, only used by macrobench
Change-Id: I516203b70bdc75b6415fa08bf9c4fb1b598b0102
Move content bounds into DrawFrameTask. This ensures
that changes in bounds are synchronized with changes in
rendering commands, avoiding potential underdraw.
Bug: 64200212
Test: Repro steps in bug. Drag up/down on resize handle, verify
no flicker.
Change-Id: I3109acf262e23c2a7d8904f1dcbfc8273aaed65b
* Move mValid to native
* Have destroyHardwareResources destroy everything
* Remove flaky mParentCount checks in setStaging
* All tree updates have an internal observer to
ensure onRemovedFromTree() is a reliable signal
* onRemovedFromTree() immediately releases resources
to avoid displaylist "leaks"
Test: Unit tests for validity added & pass, manually
verified that b/34072929 doesn't repro
Bug: 34072929
Change-Id: I856534b4ed1b7f009fc4b7cd13209b97fa42a71c
bug:30895941
Prevents a race where frame work could interleave between frames,
causing SurfaceView position updates to be delivered out of order.
Change-Id: I01e4cc557b69dcf33e877a0e16c0d115ec95e4cc
Fixes: 28218991
If a draw() happens while we are stopped, don't report
that the surface is lost because this will prompt
a tear-down of the surface which isn't desired. It can
result in ViewRootImpl ending up in an internally-bad state
in this case.
Change-Id: If3eb8c6bc8702299e5330bc0917952624dce3b7e
Bug: 27286867
WindowManager has committed to stopped state
controlling the lifecycle of the Surface, so
make that a first-class thing in HWUI as well.
This makes it more resistent to things like
a rogue updateSurface() happening while mStopped=true,
leading to bad things down the line. Instead let
the surface be changed/updated as often as desired,
and just block any attempt to draw on that surface.
Also removes some unnecessary makeCurrent()s, as
EglManager ensures that we *always* have a valid
GL context now (using a pbuffer surface if there is
no window surface set)
Change-Id: Iead78ddebc7997e8fdb0c9534836352f5e54b9bd
Bug: 27709981
This desperately needs a refactor, but to keep
the current (really needed & nice) behavior of
dispatching after sync finishes would be difficult
to handle cleanly without lots of ripping so... #yolo
Change-Id: I831a06c6ae7412a062720d68ecbe3085190f0258
This is adding the renderer side infrastructure to allow
rendering multiple render nodes with different threads.
This is a pre-step for decoupling a non client decor
resize reder from a content resize render.
Multiple render nodes can be added to be drawn, and to
prevent overdrawing, a content bounds area can be set
Bug: 22527834
Change-Id: Ie7271e20895bf38957e5a84aeefc883e282039ad
Bug: 20853441
Calculating duration that crosses the UI-RT
sync point will now subtract out the time spent waiting
in queue under the assumption that this time will be
accounted for in the previous frame's metrics
Change-Id: Ia8213f4410638840613f5ae439e98dfb77532a6a
Adds remaining missing overrides and nullptr usages, missed due to
an extreme failure in tool usage.
Change-Id: I56abd72975a3999ad13330003c348db40f59aebf
Bug: 17516789
This will force a relayout/reinitialize pass if the Surface
is lost mid-render instead of crashing on the next frame
Change-Id: If08bfa16f740728fa7c05904fa11e26f07b81e2e
