Wallpanel OS
OptimizationsSystem optimizations — part 1
WebView optimization, keeping the Home Assistant WebSocket connection alive and early Vulkan rendering work in AOSP.
While working on the next version of HA Tablet, a custom AOSP build for PoE-powered wall tablets, I focused on two areas:
- eliminating delays when the Home Assistant interface resumes after the screen wakes up,
- testing and enabling Vulkan support in Android’s rendering module.
Problem with reloading the Home Assistant page
One of the most irritating effects in the wall panel experience was that after the screen turned off and then woke up again, the Home Assistant page was fully reloaded. After unlocking, the user had to wait several seconds for the interface to load again.
To understand what was happening under the hood, I used Chromium DevTools and Wireshark. This allowed me to trace WebSocket behavior and confirm that:
- after the screen turned off, WebView slowed down JavaScript timers, including those used by the ping/pong mechanism in WebSockets,
- after about 5 minutes of inactivity, Chromium closed the WebSocket connection.
This behavior came from Chromium’s internal background throttling mechanisms. It makes sense on mobile devices, but for a PoE-powered wall panel it is undesirable. At that time, I was using the default Chromium WebView engine in version 139.0.7258.143.
Custom WebView version
To eliminate the problem, I created a custom WebView engine based on newer sources in version 142.0.7424.0, where I:
- disabled timer throttling for selected contexts,
- removed limits that closed WebSocket connections in the background,
- added the ability to test additional Chromium flags and options for Home Assistant integration.
The effect was clear: after the screen wakes up, the panel keeps its active connection with Home Assistant and the UI is available immediately, without reloading the page or waiting for WebSockets to reconnect.
Enabling Vulkan
The second area of work was enabling rendering through Vulkan instead of classic OpenGL ES. Moving to Vulkan provides several visible benefits:
- better GPU memory management,
- lower CPU overhead during UI rendering,
- higher stability and performance of Skia, the rendering library used by Android.
To enable Vulkan, I added the following entries to build.prop:
ro.hwui.use_vulkan=true
debug.renderengine.backend=skiavk
ro.surface_flinger.protected_contents=falseThe last parameter, ro.surface_flinger.protected_contents=false, turned out to be necessary because the system reported:
{
"protectedMemoryFeatures": {
"protectedMemory": 0.0
}
}This means the driver does not support the VK_KHR_protected_memory extension, also known as protected content / protected memory. In practice, SurfaceFlinger attempted to run rendering in protected mode, which the Mali / Rockchip driver does not implement.
Source code adjustment
While enabling Vulkan, I ran into an additional issue: the Rockchip/Mali DDK driver incorrectly declares support for vkGetDeviceQueue2, even though it does not actually support it. The system reports Vulkan 1.1, but the function works correctly only with the classic vkGetDeviceQueue() call.
To work around this, I modified SkiaVkRenderEngine.cpp, adding a fallback to the older call and extended logging for Vulkan context structures such as VkPhysicalDeviceFeatures2, VkPhysicalDeviceProtectedMemoryFeatures and VkExtensionProperties.
Summary
These changes improve the perceived responsiveness of the Home Assistant interface after the screen wakes up and create a foundation for further Vulkan experiments on Rockchip/Mali devices.
At that stage, the next steps were further WebView and AOSP service optimizations, Vulkan/Skia testing with the Home Assistant interface and tests of the newer 8-core 8-inch model.
