Qutebrowser working at a snail's pace

[mauricioquintela]

Version info:

        ______     ,,
    ,.-"`      | ,-` |
  .^           ||    |
 /    ,-*^|    ||    |
;    /    |    ||    ;-*```^*.
;   ;     |    |;,-*`         \
|   |     |  ,-*`    ,-"""\    \
|    \   ,-"`    ,-^`|     \    |
 \    `^^    ,-;|    |     ;    |
  *;     ,-*`  ||    |     /   ;;
    `^^`` |    ||    |   ,^    /
          |    ||    `^^`    ,^
          |  _,"|        _,-"
          -*`   ****"""``

qutebrowser v3.1.0
Git commit: 0b220117e on main (2024-03-26 14:30:20 +0100)
Backend: QtWebEngine 6.6.2, based on Chromium 112.0.5615.213 (from api)
Qt: 6.6.2

CPython: 3.11.8
PyQt: 6.6.1

Qt wrapper info:
  PyQt6: success
  PyQt5: not imported
  -> selected: PyQt6 (via autoselect)

colorama: 0.4.6
jinja2: 3.1.3
pygments: 2.17.2
yaml: 6.0.1
adblock: 0.6.0
objc: no
PyQt6.QtWebEngineCore: 6.6.0
PyQt6.sip: 6.7.12
pdf.js: 4.0.379 (/usr/share/pdf.js/build/pdf.mjs)
sqlite: 3.45.2
QtNetwork SSL: OpenSSL 3.2.1 30 Jan 2024

Style: Breeze::Style
Platform plugin: xcb
OpenGL: NVIDIA Corporation, 4.6.0 NVIDIA 550.67
Platform: Linux-6.8.1-zen1-1-zen-x86_64-with-glibc2.39, 64bit
Linux distribution: Arch Linux (arch)
Frozen: False
Imported from /usr/lib/python3.11/site-packages/qutebrowser
Using Python from /usr/bin/python3
Qt library executable path: /usr/lib/qt6, data path: /usr/share/qt6

Paths:
cache: /tmp/qutebrowser-basedir-7l2uv6wi/cache
config: /tmp/qutebrowser-basedir-7l2uv6wi/config
data: /tmp/qutebrowser-basedir-7l2uv6wi/data
runtime: /tmp/qutebrowser-basedir-7l2uv6wi/runtime
system data: /usr/share/qutebrowser

Autoconfig loaded: yes
Config.py: no config.py was loaded
Uptime: 0:00:08

Does the bug happen if you start with --temp-basedir?:
Yes

Description
Attempting to use qutebrowser after latest commit (0b22011) is essentially impossible, with the browser running at a snail's pace and (sometimes) crashing crash.txt. Latest commit was compiled after a libx11 update (see https://archlinux.org/packages/extra/x86_64/libx11/), which might be related.
Logs obtained from running qutebrowser via qutebrowser -T --debug 2>|log.txt :version : log.txt. Libva error also appears when running vainfo, although I am not sure the was the case previously:

❯ vainfo
Trying display: wayland
Trying display: x11
libva error: vaGetDriverNames() failed with unknown libva error
vainfo: VA-API version: 1.21 (libva 2.20.1)
vainfo: Driver version: VA-API NVDEC driver [egl backend]
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileVP8Version0_3          :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileAV1Profile0            :	VAEntrypointVLD
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileHEVCMain12             :	VAEntrypointVLD
      VAProfileVP9Profile2            :	VAEntrypointVLD

How to reproduce

Try to open qutebrowser under latest commit + libx11 version. Interface should be extremely slow opening any starting page (duckduckgo, searx, google, etc). Forcing qutebrowser to start in the :version page leads to normal scrolling, although opening a new tab (to about:blank) leads to same slowdown. Search boxes or typing an url can lead to crash.

[The-Compiler]

The crash is unrelated and #7901.

As for the slowness, that seems like an issue with your graphic driver or something. I just upgraded and don't notice any difference, and this is almost certainly unrelated to any recent changes in qutebrowser.

Could you try running the testbrowser script and see if it reproduces with that too?

[mauricioquintela]

Running with the testbrowser script works perfectly. It's weird if indeed it is a graphics driver issue, as no driver update has happened for a few days, with several reboots and shutdowns in the meanwhile.