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
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
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
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
This removes the duality of DisplayList, removing a small amount of
overhead
Test: buids & hwuiunit passes
Change-Id: I8bb3a20e9ead1caec4b4a8a3e9f2c08f717a7096
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
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: 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
Bug: 15838537
* Fix kSync_UIRedrawRequired constant value (woops)
* Tell CanvasContext that WebView is now rt-safe
Change-Id: Idf15cf21115c2ca24b8ccd00025e8502864cd87c
* Now with more native!
* Less matrix math thanks to bulk-property-update support!
* Zero JNI on the View.damageInParent() path!
* Fully aware of RT-driven animators!
* Likely full of new and exciting bugs!
* But it also fixes at least 1 existing invalidate bug!
Change-Id: Ie0773f85a60850ff2668370c58defef2e8aa079f
Bug: 15185239
Bug: 15238382
Make DeferredLayerUpdater ref counted so that
HardwareLayer:finalizer() works non-crashily on
leaked layers
Give DeferredLayerUpdater the ability to have a layer destroyer
set so that leaked layers can still be recycled on the
RenderThread
Order layer updates based off of pushLayerUpdate() calls to fix
issue with nested layers
Change-Id: I4449cee607f7e5126e02fed7464cf48038e3dfdf
Bug: 15118640
* Prevent over-stuffing the queue by dropping frames
* Prevent double-drawing in one pulse by RT by deferring
vsync registration until post-draw so that it catches
the next vsync pulse instead of the current one
* Bias vsync race condition towards the UI thread
* Fix queueDelay to actually work
Change-Id: Ibf584258bd93ebcbba058bd976dc8b307f1c6155
Bug: 13952590
It was attempting to flush state changes after the canvas was
destroyed, which caused layer updates to crash.
Due to the removal of SetDisplayListData, the sync mode isn't able
to do anything ever, so remove it.
Change-Id: I1e18ce288d81fd47cc6e612afda9476f75ecef2e
