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
- Rename to FrameMetrics to avoid collision with existing
android.view.FrameStats class
- Make FrameMetricsObserver implementation detail,
exposing FrameMetricsListener interface as public API
and wrapping in FrameStatsObserver to maintain state
- Remove dropped frame count call, in favor of passing as
parameter to callback method.
- Move away from raw timestamp access in favor of Metric IDs
which represent higher-level, more stable stages in a frame
lifecycle and match the categories exposed in the onscreen
bars.
- Support many-to-many Window<->FrameMetricsListener relationship
Change-Id: I00e741d664d4c868b1b6d0131a23f8316bd8c5c2
getMaximumBitmapWidth() and getMaximumBitmapHeight() of DisplayListCanvas
need HWUI cache instance. Since the initialization of the cache is
asynchronous it may crash if not yet ready. Add a staticFence() call
to guarantee the cache has been created prior issuing the call.
Change-Id: I5ed9e5cc084444c8d1872a77fef50e294ae14e93
Signed-off-by: Thomas Buhot <thomas.buhot@intel.com>
Signed-off-by: Zhiquan Liu <zhiquan.liu@intel.com>
On the critical path of the cold launch of applications
the main thread of the started application tells the RenderThread
to create a surface. This process is synchronous and blocks
the main thread of the application until the creation
of the EGLContext is complete.
As a consequence the launch time of the application is delayed
by time spent allocating the EGL Context in the RenderThread.
With this optimization the launch time of any application
is improved (for example settings by 20 to 40 ms).
Change-Id: Ibf47aaa0abb8dedf7aa00693073db3785d9d6b08
Signed-off-by: Thomas Buhot <thomas.buhot@intel.com>
Signed-off-by: Zhiquan Liu <zhiquan.liu@intel.com>
Using a multi threaded render node to render the window frame
asynchronously from the application relayout.
Bug: 22527834
Bug: 24400680
Bug: 24459827
Bug: 24409773
Bug: 24537510
Change-Id: I1010fc6a8b6e38424178140afa3ca124433ab7e4
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: 20824843
Not really a proper "benchmark mode" but it turns out
we already have reasonably good profile data, so tweak
the test app to spit it out after a run.
Change-Id: Iaee9c0d61b5508daf282fe5f95d0b37ee419a8f1
bug:19967854
Separate properties from Caches, into static, RenderThread-only class.
Also rewrites the means for java to set properties to correctly handle
threading, and adds an override for profile bars so that SysUi doesn't clutter
the screen with them.
Change-Id: I6e21a96065f52b9ecc49d1a126244804ba106fa9
Switch a few places to using android::canvas
instead of SkCanvas as well which eliminated
some JNI
Change-Id: I8f98b56442a06362b82b984cd1bd3a92398d8dbc
Switch a few places to using android::canvas
instead of SkCanvas as well which eliminated
some JNI
Change-Id: I8f98b56442a06362b82b984cd1bd3a92398d8dbc
More S's for More Speed
Split JankTracker's backing data from the
class to allow for data relocation to/from ashmem regions
Pack the jank tracking data to fit in 256 bytes
Change-Id: Ife86a64b71a328fbd0c8075fe6a0404e081f725b
Bug: 18203577
The issue occurs as a result of performTraversals() both doing
a window relayout call *and* early-returning because it's not dirty.
To fix this pauseSurface() returns whether or not the RT-side is
"dirty" to force ViewRootImpl to do a draw even if mDirty is
otherwise empty.
Change-Id: I534f367e75d18d273ebf14df3927f5c464ef6bef
Bug: 17208461
* Switch Layer to be VirtualLightRefBase instead of
Caches' side-channel ref-counting
* Include active layers in gfxinfo dump
* Run gfxinfo dump on the correct thread
* Dump gfxinfo on Layer creation failure
Change-Id: I28d195699e2334518e215ab28c7a17355aee9678
Bug: 18099195
Don't use EGL_SWAP_BUFFER_PRESERVED on surfaces that will
never benefit. Also clean up some confusing naming
Change-Id: I674ca64e0464a3282cff79e5ecd350d08f47c014
Bug: 17765082
DeferredLayerUpdater had fallen behind RT updates. Re-snap to
latest expectations, ensuring to call requireGlContext() prior
to detachSurfaceTexture to avoid leaking SurfaceTextures
Change-Id: Ic65fb9831e5284f658866da8da9ad5af1d227699
Bug: 17208461
There's a potential race condition between HardwareRenderer.destroy()
being called (which calls destroyCanvasAndSurface()) and the renderer
being finalized (which is what calls freePrefetchedLayers), during which
time it's possible we get a TRIM_MEMORY_COMPLETE and destroy the EGL
context.
Fix this race condition by moving stopDrawing() and freePrefetchedLayers()
into destroyCanvasAndSurface() where they should have been in the first
place.
Also, if we hit the assertion failure, dump the current state of
Caches to try and provide more context for the failure.
Change-Id: Ife0ba3562041e8b08e87e3e13640472b3004eed6
bug:15859361
Moves lighting info out of StatefulBaseRenderer, since it's not useful
at record time, and only used by OGLR.
Change-Id: I7ab065d02d9304afad1dc4c48597a7a621366f8e
* 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
