I’m trying to play a video in an HTMLViewer on a Raspberry Pi 5 and am getting 1-2 fps.
The same video plays fine (30 fps) in Chromium, or even in WebKitGTK’s own MiniBrowser, which is using the same WebKitGTK engine that the HTMLViewer is using.
Has anyone seen this before or know any workarounds?
Thank you, but this unfortunately seems to make no difference.
After a bit more testing, it’s not a Xojo issue. It’s WebKitGTK’s video presentation/compositing path.
It seems when it runs in a small window the video runs fine. When the browser area is stretched larger then it runs proportionately worse. Unfortunately for my application it needs to be full screen.
I think it could be related to this regression on Trixie WebKit 2.52. I’m going to try to patch it myself but if I find I’m spending too much time on it I’ll move on to another solution.
It works flawlessly in Chromium, so I may need to write a python/chromium translation layer to handle my executeInXojo function calls.
Okay, so I’ve resolved this. Stock WebKitGTK 2.52.6 on Raspberry Pi showed extremely poor HTML5 video performance as the WebKit surface grew larger.
WebKitGTK commit 36eefe856208 made changes to the DMA-BUF video path which caused this regression.
I put together a custom patch that restores the older WebKit DMA-BUF pipeline (from v2.46.6) while retaining the modern WebKitGTK 2.52.6 compositor.
Install these custom versions (64-bit ARM Debian/Trixie only): https://www.dropbox.com/scl/fo/e7xd4zcbs649kcpc91u9k/AHkjgj9pOQmPKrYUA_9Qks0?rlkey=v1038036szagxwx91d7w4bdbw&st=pbp6ukpu&dl=0
And enable the patch with the following environment variable:
WEBKIT_GST_RAW_DMABUF_BRIDGE=1
Keep in mind that a system update may overwrite these patches, so you can use:
sudo apt-mark hold libjavascriptcoregtk-4.1-0 libwebkit2gtk-4.1-0
But since it’s a web browser, WebKitGTK is fairly security sensitive, so hopefully they implement an official fix soon. But it apparently has been broken for almost two years so I’m not holding my breath.
