webview lags when zooming quickly

[jgkamat]

Version info (see :version):

qutebrowser v1.6.0
Git commit: 9b6698758 (2019-03-04 14:18:48 +0100)
Backend: QtWebEngine (Chromium 65.0.3325.230)

CPython: 3.6.5
Qt: 5.11.3
PyQt: 5.10.1

sip: 4.19.13
colorama: no
pypeg2: 2.15
jinja2: 2.10
pygments: 2.2.0
yaml: 3.13
cssutils: no
attr: 18.2.0
PyQt5.QtWebEngineWidgets: yes
PyQt5.QtWebKitWidgets: yes
pdf.js: no
sqlite: 3.25.3
QtNetwork SSL: OpenSSL 1.0.2q  20 Nov 2018

Style: QFusionStyle
Platform: Linux-4.19.0-2-amd64-x86_64-AMD_Ryzen_7_2700X_Eight-Core_Processor-with-gentoo-2.6, 64bit
Linux distribution: Gentoo/Linux (gentoo)
Frozen: False
Imported from /usr/lib64/python3.6/site-packages/qutebrowser
Using Python from /usr/bin/python3.6
Qt library executable path: /usr/lib64/qt5/libexec, data path: /usr/share/qt5

Paths:
cache: /home/jay/.cache/qutebrowser
config: /home/jay/.config/qutebrowser
data: /home/jay/.local/share/qutebrowser
runtime: /run/user/1000/qutebrowser

Uptime: 0:03:43

Does the bug happen if you start with --temp-basedir? (if applicable):
Yes
Description

When scrolling quickly, the webview can lock up (this is worse on slower computers). It seems that this is due to 2 slow config calls and displaying (and logging) info messages.

It should be trivial to disable info messages on zoom and fix the config calls, but does that (by default) sound like a good idea?

[18:34:46] <ldlework> qb zooming seems kinda fucky
[18:36:04] <jgkamat> what's wrong with it?
[18:37:54] <ldlework> for me it is suuuuuuuper laggy
[18:38:10] <ldlework> the actual percent is too sensitive and it goes zoooming too far in percent
[18:38:13] <ldlework> then freezes while it recomputes
[18:38:29] <ldlework> generally it'll recompute somewhere halfway between where I started and where the percent landed
[18:38:34] <ldlework> then it'll freeze for a few more seconds
[18:38:38] <ldlework> then recompute the final zoom level
[18:38:43] <ldlework> basically unusable for me
[18:39:03] <jgkamat> ldlework: can you check to see if the zoom is fine in chrome? (better yet kde falkon)?
[18:39:13] <ldlework> oh yeah zoom works fine in chrome
[18:39:17] <jgkamat> I haven't profiled zooming at all so it's very possible there's something crazy going on there
[18:39:36] <jgkamat> (although, I'm not sure how we can mess that up)
[18:40:05] <ldlework> I should try explicit zoom buttons rather than mousewheel
[18:40:16] <ldlework> it probably overloads qb with rerender requests or something
[18:40:27] <jgkamat> try both
[18:41:43] <jgkamat> I think it's the zoom messages
[18:43:51] <jgkamat> no way to silence on mousewheel but can you try binding to :zoom --quiet instead of just :zoom 
[18:44:55] <jgkamat> and after the messages it's the config system
[18:45:55] <jgkamat> I could probably solve both, but it would be nice to check if --quiet improves it for you (at least 40%, I think). If it does, open an issue, and I'll fix it

How to reproduce

https://youtu.be/K61o1HolnmQ

[garrett-hopper]

I've run into the same issue, but it's much more pronounced. It's taking several seconds to switch to a zoom level which hasn't been rendered yet. To my surprise, it's almost instant when switching back, which I guess is caused by some sort of cache of the zoomed layout.

(Recorded with -B $(mktemp -d))

qutebrowser --version

``` qutebrowser v1.13.1 Git commit: Backend: QtWebEngine (Chromium 77.0.3865.129) Qt: 5.14.2

CPython: 3.8.5
PyQt: 5.14.2

sip: 4.19.22
colorama: no
pypeg2: 2.15
jinja2: 2.11.2
pygments: 2.6.1
yaml: 5.3.1
cssutils: 1.0.2 $Id$
attr: 19.3.0
PyQt5.QtWebEngineWidgets: yes
PyQt5.QtWebEngine: 5.15.0
PyQt5.QtWebKitWidgets: no
pdf.js: 2.4.456 (/nix/store/l4q8w0cgda5hshll27l6pg563ihn0fcx-pdfjs-2.4.456/build/pdf.js)
sqlite: 3.32.3
QtNetwork SSL: OpenSSL 1.1.1g 21 Apr 2020

Style: QFusionStyle
Platform plugin: xcb
OpenGL: Intel, 4.6 (Compatibility Profile) Mesa 20.1.4
Platform: Linux-5.4.59-x86_64-with-glibc2.2.5, 64bit
Linux distribution: NixOS 20.09 (Nightingale) (unknown)
Frozen: False
Imported from /nix/store/fiknypd9acb18m8bbcg6jprrcm5l3kys-qutebrowser-1.13.1/lib/python3.8/site-packages/qutebrowser
Using Python from /nix/store/fjgnz0xfl04hsblsi4ym5y5akfh6mlmy-python3-3.8.5/bin/python3.8
Qt library executable path: /nix/store/3wsgawivk17ffy0m4dzxggs5saaz4lnj-qtbase-5.14.2/libexec, data path: /nix/store/3wsgawivk17ffy0m4dzxggs5saaz4lnj-qtbase-5.14.2
OS Version:

--- /etc/os-release ---
NAME=NixOS
ID=nixos
VERSION="20.09pre239318.c59ea8b8a0e (Nightingale)"
VERSION_CODENAME=nightingale
VERSION_ID="20.09pre239318.c59ea8b8a0e"
PRETTY_NAME="NixOS 20.09 (Nightingale)"
LOGO="nix-snowflake"
DOCUMENTATION_URL="https://nixos.org/learn.html"

Paths:
cache: /tmp/tmp.gCGLlwqxyS/cache
config: /tmp/tmp.gCGLlwqxyS/config
data: /tmp/tmp.gCGLlwqxyS/data
runtime: /tmp/tmp.gCGLlwqxyS/runtime
system data: /nix/store/fiknypd9acb18m8bbcg6jprrcm5l3kys-qutebrowser-1.13.1/share/qutebrowser

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

[The-Compiler]

@Jumblemuddle Can you check how things look in Chromium and/or in other QtWebEngine browsers such as Falkon?

[garrett-hopper]

I haven't actually been noticing as large delays when zooming lately, but I'm not sure what changed.
Chromium does appear to have the same behavior of having a slight delay when a new zoom level is calculated and no delay when going to a previous zoom level.

[AkechiShiro]

I'm still noticing large delays when using the zoom feature, so I'd say this issue is still legitimate to be open and still being a problem it is very hard for me to use the zoom feature since it tries to redraw eveerytime the zoom level changed, but I'd like to reach like 200% directly not wait for the rendering of the in-between for like 10 seconds then reach the right zoom level being rendered, finally.

[The-Compiler]

but I'd like to reach like 200% directly

Note you can press 200= to get that.

[kofm]

I have the exact same issue.
:version

Zooming with Ctrl + Scroll Wheel will make QB unusable until it stops rendering. Being the increment with scroll wheel very fine it's much more laggy than using + and -