FreeBSD has a handful of Qt WebEngine-based browsers. Falkon, and Otter-Browser, and qutebrowser and probably others, too. All of them can run into issues on FreeBSD with GPU-accelerated rendering not working. Let’s look at some of the workarounds.
I should mention that I personally have not hit this issue. Maybe I don’t watch enough video’s, or maybe I happen to have the right hardware to avoid the problem.
There are reported cases of Qt WebEngine-based browsers displaying video badly. If I remember correctly there was a mix-up at one point between RGB and BGR, and this bug report specifically mentions “videos with wrong colors”.
Depending on the browser, you may be able to use command-line arguments to affect hardware acceleration. The Qt documentation on WebEngine debugging mentions a number of command-line arguments that can be used to modify WebEngine internals.
Unfortunately, web browsers also parse command-line arguments.
From a little investigation, it turns out that the browsers handle the documented command-line arguments very differently:
- Falkon accepts the WebEngine-related
command-line flags that are documented. I can’t tell
if they are effective: passing
--no-sandboxstill gets me debugging messages from sandboxing code. Oddly enough,
falkon --helpmentions a
--help-allcommand-line argument, which is totally ignored.
- qutebrowser has its own special
--qt-flagto pass flags on to Qt internals. I suppose that’s because it has Python argument-processing first, followed by handing things off to Qt.
- Otter supposedly supported
--disable-gpuin the past, but now complains that it is an unknown option. Unlike Falkon, it does understand
From this collection of inconsistencies, I think the conclusion should be that the environment is a better place to do any settings that should apply to WebEngine internally – the path from command-line argument to Qt internals is too much dependent on where and when processing happens and how “cleanly” the overall command-line arguments are passed on.
The documentation says
Alternatively, the environment variable QTWEBENGINE_CHROMIUM_FLAGS can be set.
and that looks like the best way to consistently affect the behavior
of WebEngine inside an application, because it end-runs the command-line processing.
After all, far fewer applications mess with the environment (their own
environment) before instantiating
That means that people using FreeBSD, experiencing video corruption in
WebEngine-based browsers, can best put the following (or some csh equivalent)
QTWEBENGINE_CHROMIUM_FLAGS="--disable-gpu" export QTWEBENGINE_CHROMIUM_FLAGS