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
Bug: 27922347
* Dump the full histogram
* Expand the histogram to have a slow-frame section with
large 50ms buckets to raise the cap to 5s to give more
insight into system-health
* Stop excluding first-frame metrics as we want to include
those in our global tracking. Automated tests already filter
these out by doing resets before running anyway.
Change-Id: Idaba8aad591f59d10a6477b11efc0767ff715083
- 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:20063841
Restores old SkShader matrix behavior from before the Glop refactor.
Many drawing operations draw without sending the canvas transform to
the GL shader. In such cases, we need to adapt the matrix sent to the
SkShader logic to invert the canvas transform that's built into
the mesh.
Change-Id: I42b6f59df36ce46436322b95bf9ad2140795ee58
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
To obtain the gfxinfo for each process, the static method of RenderProxy is used, which is named outputLogBuffer().
In there,
1. RenderTask is created for getting DisplayList Commands in RenderNode.
2. staticPostAndWait() is called
3. RenderThread's instance is created by 'RenderThread::getInstance()' in staticPostAndWait()
In case of the service, they don't use HW Acceleration, so don't need RenderThread.
But, by the process of No.3, RenderThread is created for all process.
As we know, RenderThread never be destroyed while the process is alive.
This patch checks RenderThread instance before the creation of RenderTask.
And, there is no one, just return to prevent the unnecessay creation of it.
Change-Id: I4fe29d83c9ced3e8b67177c0874c5d8ee62e1870
Adds remaining missing overrides and nullptr usages, missed due to
an extreme failure in tool usage.
Change-Id: I56abd72975a3999ad13330003c348db40f59aebf
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
