Age | Commit message (Collapse) | Author |
|
The target work duration in HWUI ADPF is sometimes incorrect, and
is more often incorrect during buffer stuffing recovery due to the
exposure of new jank. The issue causes CPU clock frequencies to
decrease too much, and cause potential jank in subequent frames.
The original frame deadline should be used instead in calculating
the workload target deadline when triple buffered because even when
the deadline is pushed later during buffer stuffing, the throughput
requirements remain the same.
Also fixes a misordering in FrameInfoNames that was inconsistent
with FrameInfo and FrameMetrics.
Bug: b/389939827
Test: atest JankTracker
Test: presubmit, perfetto traces w/ and w/o buffer stuffing recovery
Flag: com.android.graphics.hwui.flags.calc_workload_orig_deadline
Change-Id: I2e3da6ee927d20fcbc9299ab5eda5732660d7246
|
|
1. preload eglContext when renderthread preload is called so setSurface
work is not waiting for this work during app launch crit path.
2. Additionally queue GraphicBufferAllocator instance get, so
allocateBuffer does not wait for initialization during app launch
critical path.
Impact: Large improvement in app launch latency for low core devices
- ~70ms of improvement in our view based app launch
- ~27ms of improvement in material3 compose base app launch
Test: manual built and flashed
Bug: 383612849
Flag: early_preload_gl_context
Change-Id: I580e31de1d3a9878cf102dfdcad39bfd64bf2c53
|
|
Rounding discrepancies in the image codec infrastructure was allowing
gainmaps to be decoded with a 1px border on the edge, which introduces
visible seams when zooming into large images.
Fix this by adjusting how computing the desired gainmap subregion size,
by pretending we downsample first, then compute the subregion size based
on that.
Add a long paragraph explaining why we have to do this with an example,
because it's not entirely intuitive.
Also adjust how we poke at the gainmap resampling flag, since some CTS
tests run before RenderThread starts up and intializes the properties.
Bug: 371123308
Flag: com.android.graphics.hwui.flags.resample_gainmap_regions
Test: Decoding in Photos and Files
Test: GainmapTest
Change-Id: Id608c5838f7890d0304b040e13d7281aa879a75c
|
|
Setting up a device queue with a global queue priority above the system
default requires sufficient privileges (SYS_NICE) otherwise queue
creation will fail.
SurfaceFlinger and system_server have SYS_NICE and will set priority to
REALTIME. SysUI and Launcher take that as an indication they should
request HIGH for better preemption strategy. However for upstream DRM
drivers, we currently lack a way to grant them granular access to HIGH
but not RT. For long term, the right way to do this is via drm specific
cgroup for scheduling controls however this is currently being worked
on upstream.
In the meantime, instead of fatally crashing, we can query the global
priorities supported before queue creation and if its not supported,
drop the priority request and log a warning.
Note this requires vkGetPhysicalDeviceQueueFamilyProperties2 which is
provided by Vulkan 1.1 while the global priority query can be safely
added to the pNext chain and will be ignored if
VK_EXT_global_priority_query isn't supported.
Bug: 343986434
Flag: com.android.graphics.hwui.flags.query_global_priority
Test: UI comes up debug.renderengine.backend=skiavkthreaded
Change-Id: I662c9ce3f3724e87690e25d260ee010340451c53
|
|
We want eglCreateContext telemetry to give us insights into how
developers use EGL. Including HWUI telemetry in this pollutes this
telemetry. Skip recording of the creation of this context using the new Egl extension. Currently this only disables the passing of GpuStatsInfo::Stats::CREATED_GLES_CONTEXT to the gpu stats.
Test: Checked the code path executed correctly with the flag enabled/disabled using logging
Bug: 347911216
Flag: com.android.graphics.hwui.flags.skip_eglmanager_telemetry
Change-Id: Ifcadd5af263f26388026bcd70ec8dc9c2914cd0a
|
|
Implicitly, region decoding is a cropping operation, which previously
was introducing quality issues when decoding a gainmapped image. For
instance:
(a) Consider a 48x48 image with a 12x12 gainmap.
(b) Consider decoding a 10x10 region of the image. The decoder must choose
to either decode a 2x2 or 3x3 region of the gainmap, which does not
match the 4x scale ratio of the source, so either we decode too much
or too little of the image
(c) When displaying the image, we bilinearly scale both the image and
the gainmap to the destination, then apply the gainmap. But, because of
(b), the gainmap is misaligned with the base image, introducing haloing
artifacts.
To fix this, we change (b) by always decoding a slightly larger
region (in the examplar case, either a decode a 3x3 or 4x4 region), but
retain information about the "logical" region we intended. Then, we
resample from the "logical" region up to the decoded bounds.
In the above example, this means that we decode a 3x3 or 4x4 bitmap,
that holds the logical 2.5x2.5 region of the gainmap, ensuring that (0, 0)
in the resulting bitmap maps to (0, 0) in the bitmap for the decoded region
from the base image, so that the gainmap content lines up with the base
image after the gainmap is upsampled during rendering.
We do the actual resampling inside of the recycling allocator, since we
sometimes perform a bitmap copy there anyways, so we can resample during
the copy.
Hide this behind a flag, since I broke decoding in about 5 different
ways before settling on this.
Bug: 352847821
Flag: com.android.graphics.hwui.flags.resample_gainmap_regions
Test: Decoding works in Photos, Files, and modified SilkFX
Change-Id: Ic21d44011858619273b11c20ee746614a1749a73
|
|
2eb7e9d8a8
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/3198371
Change-Id: I0c06b96ac45a93d161f16c4b3b931fb3167feaf5
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
... to give SwiftShader some more time to complete.
Bug: b/354222246
Test: CtsUiRenderingTestCases x100
Change-Id: I943249a84daa873508bddcfc532048ef71eb4129
|
|
Even though more and more devices are running Vulkan, many apps still
use GL, instead of or in addition to using HWUI. Initialize GL as part
of the zygote step. This only happens once at boot - new app processes
won't do this again, so it speeds up app startup time. And since it
happens before forking the zygote, it starts off in shared memory. If an
app never uses GL, it won't have to use any memory for this GL state.
Use a new static method on Properties, rather than a static bool, as is
done for several other properties, because this happens before loading
other properties.
Bug: 335172671
Test: manual verification via log statements
Flag: initialize_gl_always
Change-Id: I80b366121db0034131afb656ea774e37171f223b
|
|
It uses android-base properties now, so is compatible with host.
Bug: 322360037
Test: build libhwui on host
Change-Id: I6502fe3001aac3d95ea2cd2c8327b8fe7baae55a
|
|
|
|
Bug: 319164766
Test: comparing traces with debug.hwui.skia_tracing_enabled on and off
Change-Id: Ie24e3b4705380ef143699f229469226df7b4913a
|
|
f9a31c7297 am: 74c7d271c4
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/2819917
Change-Id: If6f9cb0298f5a84a3b616f747afe21fd3c2e704f
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
Pixel has been using Vulkan in libhwui for several years now. We
strongly recommended using it in the Android 14 (U) CDD, and we plan to
make it MUST in Android 15 (V). Update the default to match.
Bug: 293371537
Bug: 301558076
Test: CtsUiRenderingTestCases, CtsGraphicsTestCases
Change-Id: I106381fadf6a686127cb6120afbaef53db5c4aa8
|
|
Picking sRGB primaries and transfer with extended range bit as the
dataspace, because that's straightforward for EGL.
Then, rather than dimming SDR content, we instead just render as normal
so that we take advantage of the full bit depth
Bug: 236745178
Test: builds
Change-Id: Ica39a2c81be508effb97a8850b0c8e272c10a084
|
|
Clip SV to its ancestor clipping bounds. This enables
Z-above SurfaceView + scrolling containers to work more naturally
Replaces the hidden API of setEnableSurfaceClipping
Fixes: 298621623
Test: Sample app
Change-Id: Iaa862598e37065677f5ba163a5ac7a6fab2739ea
|
|
This reverts commit aa3e498bbc9825b8c07a2094dc83e15b6bb47ffc.
Reason for revert: Synchronization with WebView is hard.
Also:
* All currently shipping devices that turn Vulkan on for HWUI support at
least two graphics queues, with the exception of emulators using
swiftshader.
* Using two graphics queues doesn't significantly regress RAM on those
devices
Bug: 280564832
Test: DailyMail app
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:219997a1e7c07a70aa935f09dbff9fb53ed03cb7)
Merged-In: Ica0c461af9df771292967ed10df63b2aa6902ae3
Change-Id: Ica0c461af9df771292967ed10df63b2aa6902ae3
|
|
This reverts commit aa3e498bbc9825b8c07a2094dc83e15b6bb47ffc.
Reason for revert: Synchronization with WebView is hard.
Also:
* All currently shipping devices that turn Vulkan on for HWUI support at
least two graphics queues, with the exception of emulators using
swiftshader.
* Using two graphics queues doesn't significantly regress RAM on those
devices
Bug: 280564832
Test: DailyMail app
Change-Id: Ica0c461af9df771292967ed10df63b2aa6902ae3
|
|
am: 8adc586787 am: 61699386a1
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/2495575
Change-Id: I6270a638338901c009909cba0fd222aa4585b2c1
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/2495575
Change-Id: Ie5d699819c295b25ac8b2f9f579235b957140f71
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
set framework/base/libs/hwui/Debug.h DEBUG_INIT to 1
then compile libhwui, there is a error
Bug: 274030026
Change-Id: Ic8857b0510c720b8108bde470a6a00e737c1f6fa
Signed-off-by: tangcheng <tangcheng@xiaomi.com>
|
|
008dc4a408
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/22087306
Change-Id: Ib11412242ecb2af89520045b2559899746f30460
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
To accelerate tuning of the value allow it to be sysprop driven
Bug: 273624684
Test: change prop, verify silkfx headroom changes after re-launch
Change-Id: Ibad662b7ba06bd821c7a3ce48c19f4c94c716b5e
|
|
This also makes a use of src/core/SkTraceEventCommon.h explicit.
These are small steps toward removing Skia's src/core from
the hwui include search path.
Change-Id: I4fe843a4e44a675748bfe2cef329202eb4dab7bf
Bug: skia:13983
|
|
Bug: 259248961
Test: none?
Change-Id: Ieb6cc796e31ae5567206a07ae61391ac91ed488d
|
|
* Make HWUI disabled by default for vendors
* Explicitly enable in supported devices
* Consolidate flags for HWUI and SF
Bug: b/261628396
Test: manual
Change-Id: I2d6b53459e4f9643e6b0bf2ba81eb4db36fb94b4
|
|
Should be a mostly no-op but adds a handful of new options
* Adds a 'MemoryPolicy' to mostly consolidate memory settings
* Moves trim handling into HWUI proper
* Adds settings for UI hidden & context destruction that's not
dependent on TRIM signals
* Treats persistent process the same as system_server
* Tweaks HardwareBitmapUploader timeout to reduce churn
Bug: 245565051
Test: builds & boots
Change-Id: I1f1b3db884ef7fa45ff2556436464a99440b998e
|
|
|
|
This reverts commit 7024d83459ec847b57527332d86fc12022b87227.
Reason for revert: Performance regression
Bug: 221813628
Fixes: 224677119
Change-Id: I276067cd8183b5b30914a78cbe48315ad7d7170d
Test: perfetto
|
|
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
|
|
This can provide useful information when diagnosing jank. It also
introduces a little bit of overhead, which is why we haven't turned it
on before. That said, the overhead is only relevant during tracing.
Bug: 221813628
Test: perfetto
Change-Id: I311d902797e0b9ecf53631f2f9f2df6cf4860635
|
|
58745e540e am: 6c8f89e428
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/16007299
Change-Id: I6c4f7dd465be57034b8f32aa4539c3a098330dfa
|
|
Updated logic to determine if RenderEffectCache
is supported to very both the vendor name as well
as the corresponding driver version.
Bug: 193145089
Test: Added test to EglManagerTests + RenderEffectCapabilityQueryTests
Change-Id: Ia0fd66c40790b94566f495d2c4128c4988d406b6
|
|
69617682e4 am: 53290d8b19 am: 15fcba18e1
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/15882028
Change-Id: I9112e09456fb346e370446246c4f01a42ac63d43
|
|
Added property to conditionally cache SkImage instances
with SkImageFilters applied. Some GL vendor implementations
invoke Fence::waitForver without signalling, leading
to ANRs throughout the system.
Bug: 193145089
Test: manual
Change-Id: I3e478b11b66205d96e9499a362f7412a1d6e952d
|
|
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/15559504
Change-Id: I9438a92ab7df133bd77ae9e59c6aa82f8809535d
|
|
Change the default value of the sysprop to be true.
Bug: 173671170
Test: install webview apks from Vasiliy, make sure surface control is
used.
Change-Id: Idf495a2be3b2bdba4fdaa380a5dbe9fd96158a97
|
|
Properties::isDrawingEnabled can unexpectedly return true
even if the system property debug.hwui.drawing_enabled is false,
if its called before RenderThread is created.
This commit changes the underlying logic to lazy load the
debug.hwui.drawing_enabled prop value.
Bug: 193920054
Test: call HardwareRendererCompat.isDrawingEnabled()) from a new test
Change-Id: Ib69577745c26595ed3964a4341086138dd5d34b0
(cherry picked from commit 8e1ab42f51c501949211746c46a02a7564ebf292)
|
|
This feature is intended for use in headless test environments,
where disabling drawing has minimal compatibility impact and can
save significant resource usage when running UI tests.
This feature is controlled via a new system property
'debug.hwui.drawing_enabled', and a HardwareRenderer public API that can
override the property value on a per-process basis.
Bug: 188559292
Test: boot emulator, atest CtsGraphicsTestCases
Change-Id: I93c21e680382e03342f235dbf58bd7a5c8a6f767
|
|
The boolean system property is named as "debug.hwui.webview_overlays_enabled"
Bug: 192267127
Test: change the property value, check presence of Webview Surface
Control
Change-Id: I01e3e26282a5fa79aa504a6e49c5abe1a1c3ea02
|
|
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
|
|
Test: this
Bug: 187718492
Change-Id: I171b5c15cd18645c2da1cffffa9635f83f8877e6
|
|
Added additional shader stretch effect type
to distinguish between shader based stretches that
are configured in HWUI as well as those that
are configured in both HWUI and SurfaceFlinger
Bug: 184297961
Test: manual
Change-Id: Ie1083cef7cbaf4f877783d67d429af7f5edd0a3c
|
|
Supports SurfaceViews & everything
Test: setprop debug.hwui.stretch_mode 1
Bug: 187718492
Change-Id: I9a222fa4c1a40e80a74cdaf75becb9524cbeed9b
|
|
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
|
|
62d82e0b33 am: 4ba8fde9ba am: de535f6eb2
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/1625662
Change-Id: Ia613c23fb779697882f9928b15684fb1ff97e9cd
|
|
`ro.kernel.qemu` is deprecated.
Bug: 182291166
Test: presubmit
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Id42d79af90b1fe7e182a96c53c84248e81a7c259
|
|
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
|
|
0 and -1 both meant default when 0 should mean
0 and -1 should mean default
Test: manual
Fixes: 179290765
Change-Id: Ia9aa5e3d83757282bfff776e083d6b3d7d29e9c0
|
|
* Degrade error when changing the rendering backend from Properties to
no longer be fatal.
* Support using a single graphics queue for the Vulkan backend. Cloud
devices only support a single queue and some Vulkan implementations such
as Swiftshader expose only one queue for simplying their implementation,
so we'll need to support one.
Bug: 175618060
Bug: 162628999
Test: hwui_unit_tests
Test: experiment on Pixel 4 enforcing a single queue (settings app,
maps, sysui)
Change-Id: I495fcabc3c89bd62bbb833998eab4944c6660f6f
|