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-sandbox still gets me debugging messages from sandboxing code. Oddly enough, falkon --help mentions a --help-all command-line argument, which is totally ignored.
  • qutebrowser has its own special --qt-flag to 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-gpu in the past, but now complains that it is an unknown option. Unlike Falkon, it does understand --help-all.

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 QApplication.

That means that people using FreeBSD, experiencing video corruption in WebEngine-based browsers, can best put the following (or some csh equivalent) in their .profile:

    QTWEBENGINE_CHROMIUM_FLAGS="--disable-gpu"
    export QTWEBENGINE_CHROMIUM_FLAGS