behaviors
Updated HWUI to toggle overscroll stretch
implementation based on whether the
device supports high end graphics
or not
Bug: 187718492
Test: manual
Change-Id: I13a91a8861c07bec8af43268ba22d0f5b7060b4f
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
- 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
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
When getting DISPLAY_EVENT_FRAME_RATE_OVERRIDE from SurfaceFlinger,
expose the overridden frame rate to the relevant application
if the current refresh rate allows that.
Bug: 169271059
Bug: 169271062
Bug: 170503758
Test: manual test using SF backdoor
adb shell service call SurfaceFlinger 1039 i32 <uid> f <refresh rate>
Change-Id: I6ae1a98e6ca13e9d3d095a5713a6b0ca99652256
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
Bug: 155905258
Test: make and boot
It is tightly integrated with android.graphics.HardwareRenderer, and
this follows on I30d34055b6870dc1039f190a88f4a747cee17300, which moved
the native component into android_graphics_TextureLayer.cpp, and
Ifa044281a3c36cbc1b413175711e9b172cda640f, which registers its JNI along
with other graphics classes.
Make TextureLayer AutoCloseable, replacing destroy() with close(). Add
annotations where appropriate.
Change-Id: I1b146ff02a20751246636144c88fe6f8eec43514
DMS should be queried before RenderProxy is first created. Otherwise
JankTracker will be initialized with bad offset information, which
breaks the dequeue time forgiveness checks and causes apps to report
longer rendering times than they should.
Also, fix the default for the presentation deadline - the default should
align with SF's offset to be 0
Bug: 155490805
Test: builds, boots, verified that offsets are plumbed at the right
time.
Test: quickstep benchmark shows improved jank numbers
Change-Id: I51538a02969eb312df40cad5df48619433056de9
With HWUI becoming an APEX module, we need to use public apis wherever
possible - since there aren't plans to expose a stable api for physical
display information through native, instead grab the system context
from ActivityThread so that we can use DisplayManager's public apis.
The api for retrieving the system context is left as a hidden api - a
future change should stabilize the API or switch to a new api that does
not yet exist. But, this is the right shape for plumbing through the
display information, as the old code retrieved it through SurfaceFlinger
which should not be stabilized as the source of truth for display
information is DisplayManagerService.
Bug: 146387012
Bug: 150880248
Test: builds, boots, verified that the correct display info is plumbed
down
Change-Id: I1a99a72244969bdece2903993e3beb27a6e534b1
Whenever an activity's configuration is updated, then tell
HardwareRenderer about it. That way, visualizating frame info does not
need to learn the display density from SurfaceFlinger, which reduces the
native-side api surface for displays.
For now, this method is kept hidden and will be stabilized when
HardwareRenderer's apis are stabilized for Mainline inclusion.
Bug: 146387012
Test: boots, builds
Test: jank visualizer
Change-Id: I51d2964bb78882516ebdff05b80819814894bdce
Previously we didn't assign a colorspace to the pipeline until it
was provided a surface to render into. This resulted in undefined
behavior if the application attempted to render an offscreen layer
before the OS provided the main window with its surface. Now instead
of deferring setting whether or not the application is wide gamut we
do initialize it to a default setting when the pipeline is created.
Bug: 148042673
Test: apct/device_boot_health_check_extra_postsubmit
Change-Id: I84d743511e949ac977486470bb14eec936de7f88
Introduce HardwareRendererObserver to isolate the android.graphics
package from the android.view package. The native code that
interacts with the observer was also moved from libandroid_runtime to
libandroid_graphics to keep it within the confines of the UI Rendering
module.
Bug: 137655431
Test: CtsUiRenderingTestCases
Change-Id: Ibccecbeda0c4d9501d86514a53eb98548233ba6a
Test: CtsGraphicsTestCases, CtsUiRenderingTestCases,
CtsRenderscriptTestCases
This is significantly faster than passing the Java object down and then
calling a JNI method to retrieve the pointer. See
https://buganizer.corp.google.com/issues/16656908#comment19
In some cases this changes what used to be native crashes (due to
android::BitmapWrapper:assertValid's LOG_ALWAYS_FATAL_IF) into
NullPointerExceptions (if a caller used a null Bitmap).
In addition:
- Remove unnecessary JNIEnv param from toBitmap(jlong)
- Change instances of toBitmap(JNIEnv*, jobject) to the above
- Replace calls to GraphicsJNI::getSkBitmap() to inline calls to
toBitmap/getSkBitmap
- make Canvas#nInitRaster @FastNative (FIXME: Could these be
@CriticalNative?)
Change-Id: I6194097be1b6e6952eba70e1e7052a5a250eed93
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
Previously setColorMode must be called before view is set, and has no effect
after that. The state of WCG on Android when this patch was written, was that
most hardware out there can not handle mixed color spaces composition well
which results in GPU composition. And this situation will remain true for a
long time.
Despite photography applications want to have WCG, it's a power cost especially
during video playback. In order to mitigate this fact and the desire to move
the ecosystem forward in WCG, we make setColorMode togglable such that in the
next app vsync, when color mode is changed we issue a surface update which
results in the old EGLSurface or VkSurface being destroyed and new EGLSurface
or VkSurface being created with the target color space being set. As a result,
applications can now togglable WCG on/off.
BUG: 120288123
Test: Build, flash and boot. Verify with SurfaceFlinger dumpsys on demo app.
Change-Id: I09bf8c380a01f4dde364873d37b248cedc6ccfd3
Split out the View/ViewRootImpl bits from the
hardware rendering bits.
Create a potential public API surface for
hardware rendering
Bug: 112709971
Test: builds & boots
Change-Id: I9e6f44b07a170574a905f42338282c4bb7e95f56
