High DPI overview

[The-Compiler]

I'm trying to figure out how well qutebrowser works with High DPI displays, without actually using one myself (yet) 😉

OS X

Seems to work fine since b065d8e (see #1404)

Windows / Linux

I've told people to set QT_SCALE_FACTOR/QT_AUTO_SCREEN_SCALE_FACTOR/QT_DEVICE_PIXEL_RATIO (deprecated in Qt 5.6). Maybe I should set the Qt::AA_EnableHighDpiScaling application attribute so that happens automatically?

People using qutebrowser on a high DPI screen - do you have one of those set? How well does it work?

---

Also see #1586.

[samuelallan72]

Works fine for me with the following:

• macbook pro retina
• i3 on Arch Linux
• default-zoom = 175% (without it, the webpages are zoomed out waay too much)
• "*dpi: 192" and "Xft.dpi: 192" in Xresources

I have dpi set to 192 in Xresources, but other than that, I don't think I've done anything else (hadn't heard of the QT env vars) to tell the system it's on a highdpi screen.

[ganwell]

Works fine.

First:

• Dell XPS 13 9350
• Debian Jessie but qutebrowser chrooted in stretch (testing)
• DPI detected correctly

Second:

• Samsung UHD Screen
• Debian Jessie but qutebrowser chrooted in stretch (testing)
• DPI set manually (see below)

You only have to set the DPI on the X-Server correctly. Everything
else works out of the box. This is true not only for qutebrowser but
of almost every GUI program. There are few programs that don't scale
Icons.

BUT not every graphics card will detect the DPI correctly. If it
doesn't you have to set it manually:

Xorg:

-dpi int screen resolution in dots per inch

I realize I have a default zoom. Maybe one improvement would be to scale the zoom according to DPI. I guess there is a Qt API to get the current DPI.

BUT that is definitely not a general Qt problem. Every other Qt-GUI works correctly without any variables or anything.

[samuelallan72]

+1 to scaling zoom with dpi. 👍

[The-Compiler]

I think that's what setting Qt::AA_EnableHighDpiScaling does at least with QtWebEngine - not sure if it does the same with QtWebKit too or if I'd need to take care of that (if I can).

[ganwell]

My state with QtWebEngine and master on 2016-08-24:

• Zoom defaults don't work well, yet
• Zoom sometimes gets lost

Therefore:

• I use QT_SCALE_FACTOR=2
• And set all the fonts to 5pt

Also:

• Non integer QT_SCALE_FACTOR cause strange behavoir ie. 1.6

[samuelallan72]

Update: I've discovered that with QT_AUTO_SCREEN_SCALE_FACTOR=1 set (and obviously the correct dpi settings for the x server), high dpi seems to be supported out of the box (this is master with webkit backend by the way) for me - no fiddling with zoom settings required. :)

[nicktelford]

$ qutebrowser --version
qutebrowser v0.8.2
Git commit: 

CPython: 3.5.2
Qt: 5.7.0
PyQt: 5.7

sip: 4.18.1
colorama: no
pypeg2: 2.15
jinja2: 2.8
pygments: 2.1.3
yaml: 3.12
cssutils: no
typing: yes
PyQt5.QtWebEngineWidgets: no
pdf.js: no
Webkit: 538.1
Harfbuzz: old
SSL: OpenSSL 1.0.2i  22 Sep 2016

Platform: Linux-4.6.4-1-ARCH-x86_64-with-arch, 64bit
Desktop: xmonad
Frozen: False
Imported from /usr/lib/python3.5/site-packages/qutebrowser
OS Version: 

--- /etc/os-release ---
NAME="Arch Linux"
ID=arch
PRETTY_NAME="Arch Linux"

With my .Xresources containing:

Xft.dpi: 250
*dpi: 250

Using a default configuration, I get the following results:
Running: qutebrowser:

Using: QT_AUTO_SCREEN_SCALE_FACTOR=1 qutebrowser:

Using: qutebrowser with a default-zoom of 250%:

[The-Compiler]

@nicktelford huh?

[nicktelford]

Sorry, I git "comment" before I'd finished adding everything :)

[nicktelford]

Using QT_AUTO_SCREEN_SCALE_FACTOR=1 seems to get closest to ideal, however there's some weird rendering issues with the UI elements, in particular, the tabbar:

• favicons render very blurry (and slightly too small)
• indicator width becomes much wider (I guess indicator-width is being scaled, this might be desirable tbh)

Using default-zoom isn't really workable, since images get zoomed (as you'd expect), and this can corrupt some images on a page (the "BBC News" logo in the linked image).

[The-Compiler]

So I just enabled Qt::AA_EnableHighDpiScaling in git master - I can't really test it yet (my highdpi laptop will finally arrive this or next week though, I hope...), but I'd love some feedback!

This should be equivalent to setting QT_AUTO_SCREEN_SCALE_FACTOR=1 FWIW and should at least scale stuff up with QtWebEngie.

[Xananax]

Doesn't really work for me...
On XPS15 15.6" 3840 x 2160 , Arch

DPI set in .Xresources:

*dpi: 200
Xft.dpi:200

(if I understand correctly, my screen has a 282 DPI resolution, but when I set the dpi to 282, everything was enormous, 200 seems like a good balance)

Here's how qute looks natively

Here's with QT_SCALE:

The font, weirdly, gets very large kerning, and the page itself gets way too big

I think it's a problem with Qutebrowser, because everything else seems to work
for reference, here are a few other Qt apps:

As you see, Krita has a few problems with icons and such, but generally readable

And here's how chromium looks: http://i.imgur.com/hKFgHul.png

For the moment I'm making do with zooming, but any workaround or explanation of what I'm doing wrong would be welcome

[JonathanReeve]

I can't quite seem to find the perfect mix of settings for hiDPI. Here are the things I've tried so far (on QtWebengine):

1. Using adefault-zoom of 200 and big font sizes: this almost works, except for the QT bug that won't zoom the page until it's fully loaded. This means that some sites like Twitter that never fully load look tiny until you press =. An annoying bug.
2. Setting QT_AUTO_SCREEN_SCALE_FACTOR=1: this makes the UI the right size, but web pages are zoomed in too much. I can set a default zoom of 50% or 75%, but then I have the same problem as in 1, but in reverse.
3. Setting QT_SCALE_FACTOR=2 and using 5pt fonts: this works the best so far, but any UI (tooltips, right-click menus, etc) is about twice as big as it should be.

So each method has its bugs. I'd love any advice about how best to tweak Qutebrowser so that websites and UI elements are all at the right zoom level.

This is with v0.9.1, by the way.

[lahwaacz]

@Xananax

(if I understand correctly, my screen has a 282 DPI resolution, but when I set the dpi to 282, everything was enormous, 200 seems like a good balance)

Note this note from the Arch wiki:

While you can set any dpi you like and applications using Qt and GTK will scale accordingly, it's recommended to set it to 96, 120 (25% higher), 144 (50% higher), 168 (75% higher), 192 (100% higher) etc., to reduce scaling artifacts to GUI that use bitmaps. Reducing it below 96 dpi may not reduce size of graphical elements of GUI as typically the lowest dpi the icons are made for is 96.

I'd imagine the note applies to HiDPI as well. In your case 200 / 282 = 0.7092198581560284, which might be the cause of the "large kerning" and "few problems" in Krita.

Maybe @nicktelford could also try to change the DPI in his .Xresources accordingly.

[bovine3dom]

I'm using Qutebrowser 0.9.1 on a HiDPI display on Windows, and it works pretty nicely out of the box, with everything appearing at sensible sizes without any fiddling around.

However, the kerning makes text look quite strange. Here's a picture of Firefox vs. Qutebrowser:

and the Qutebrowser settings page:

Do you have any suggestions as to how I would go about troubleshooting this? I realise it might be a niche gripe. Thanks.

[The-Compiler]

You could play with the fonts -> web-family-* settings, but I doubt there's much you can do. This might improve once there's a Windows binary with a newer Qt version and QtWebEngine (the new backend) though.

[nicwest]

Hey there I'm having an issue where by dropdown boxes stop working when I use QT_AUTO_SCREEN_SCALE_FACTOR=1 or QT_SCALE_FACTOR=2.

attached is some video, qutebrowser1.webm is without scale and qutebrowser2.webm is with QT_AUTO_SCREEN_SCALE_FACTOR=1

qutebrowser-vids.tar.gz

source for my awesome demo site here:

<html>
  <body>
    <select name="foo">
      <option value="1">one</option>
      <option value="2">two</option>
      <option value="3">three</option>
      <option value="4">four</option>
    </select>
  </body>
</html>

qutebrowser v0.9.1
Git commit: 

CPython: 3.6.0
Qt: 5.8.0
PyQt: 5.7.1

sip: 4.19
colorama: 0.3.7
pypeg2: 2.15
jinja2: 2.9.5
pygments: 2.2.0
yaml: 3.12
cssutils: no
typing: yes
PyQt5.QtWebEngineWidgets: no
pdf.js: no
Webkit: 538.1
SSL: OpenSSL 1.0.2k  26 Jan 2017

Style: QFusionStyle
Platform: Linux-4.9.8-1-ARCH-x86_64-with-arch-Arch-Linux, 64bit
Frozen: False
Imported from /usr/lib/python3.6/site-packages/qutebrowser
OS Version: 

--- /etc/os-release ---
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
ID_LIKE=archlinux

--- /etc/arch-release ---
Arch Linux release

--- /etc/lsb-release ---
LSB_VERSION=1.4
DISTRIB_ID=Arch
DISTRIB_RELEASE=rolling
DISTRIB_DESCRIPTION="Arch Linux"

Paths:
config: /home/nic/.config/qutebrowser
data: /home/nic/.local/share/qutebrowser
system_data: /usr/share/qutebrowser
cache: /home/nic/.cache/qutebrowser
download: /home/nic/Downloads
runtime: /run/user/1000/qutebrowser

[The-Compiler]

@nicwest probably you're seeing this Qt bug.

[nicwest]

@The-Compiler cheers, I'll update when it's fixed.

[akz92]

I'm not sure if my problem relates to this issue, but the tabs favicon are low-res for me

[The-Compiler]

@akz92 is that with qutebrowser v0.10.1 on macOS?

[akz92]

Exactly @The-Compiler, this is the output of --version:

qutebrowser v0.10.1
Git commit: v0.10.1 (2017-03-08 06:25:24 +0100)
Backend: QtWebEngine

CPython: 3.6.0
Qt: 5.8.0
PyQt: 5.8

sip: 4.19.1
colorama: 0.3.7
pypeg2: 2.15
jinja2: 2.9.5
pygments: 2.2.0
yaml: 3.12
cssutils: 1.0.1 $Id$
typing: yes
PyQt5.QtWebEngineWidgets: yes
pdf.js: 1.6.210 (bundled)
Webkit: no
SSL: Secure Transport, macOS Sierra (10.12)

Style: QMacStyle
Platform: Darwin-16.5.0-x86_64-i386-64bit, 64bit
Frozen: True
Imported from /Applications/qutebrowser.app/Contents/MacOS/qutebrowser
Qt library executable path: /Applications/qutebrowser.app/Contents/MacOS/PyQt5/Qt/libexec, data path: /Applications/qutebrowser.app/Contents/MacOS/PyQt5/Qt
OS Version: 10.12.4, x86_64

[The-Compiler]

Does setting QT_AUTO_SCREEN_SCALE_FACTOR=1 in your environment make things any better?

[akz92]

Unfortunately no, everything stayed the same.

[foliea]

Qt.AA_UseHighDpiPixmap seems to work on non hidpi displays too.

[dvs1]

I'm using an iMac and v1.0.1 from source.

Webpages are normal (I have no complaints).
However, the UI (statusbar, tabs, ...) font is smaller than desired.

export QT_AUTO_SCREEN_SCALE_FACTOR=1
export QT_SCALE_FACTOR=2

That changes webpages; therefore, it is not desirable.

I used :config-write-py --defaults, opened ~/.qutebrowser/config.py
and then changed the following from 8pt to 14pt (slightly large but easy to read).

c.fonts.completion.category = 'bold 14pt monospace'
c.fonts.completion.entry = '14pt monospace'
c.fonts.statusbar = '14pt monospace'
c.fonts.tabs = '14pt monospace'

I'm content... for now. 😎 ✌️

[nicktelford]

@dvs1 honestly, 8pt sounds incredibly small. 14pt seems much more reasonable, though it will depend hugely on how closely the configured resolution of your screen matches the actual resolution (and by "resolution", I'm talking about the DPI, not the "screen dimensions").

It's worth remembering that 1pt = 1/72 of an international inch; or ~= 0.353mm - therefore, 8pt should be around 2.8mm on your screen while 14pt will be around 4.9mm.

I don't know how good your eyesight is, but in my experience anything smaller than around half a mm becomes quite small to work with!

[dvs1]

@nicktelford

I agree that 8 seems low for a default.
I'm used to seeing 12 as the default in most programs.

Also, your fix for the favicons worked for me. Thanks. 😎 👍

[The-Compiler]

Some updates about this:

• Blurry favicons were fixed with fix blurry favicons on hidpi displays #3129
• In 341e8ca I added a qt.highdpi setting which is the equivalent of setting QT_AUTO_SCREEN_SCALE_FACTOR=1. It's off by default as it causes trouble for some people, though.
• I bumped up the default font size for everything to 10pt in 22f3fad which is hopefully a good compromise. Let the bikeshedding begin! 😉

I think this is as good as it can be right now, so I'm closing this.

[rien333]

My qutebrowser is sort of in a weird state rn from messing with dpi related environment variables (which I can't get really get anything good out of), is changing the default zoom a viable option? It seems that some web elements might get weird and images might get too zoomed (or too far off) if you change the default zoom value.

[prosoitos]

FWIW and even though this is an old issue, here is my experience (just got a high DPI machine).
I am Running Arch Linux, Xorg and EXWM.

• setting qt.highdpi to true didn't seem to have any effect
• playing with the fonts.web.size worked great for some websites but others (e.g. Facebook) were a disaster

Eventually, I settled to:

• changing zoom.default to 140% (fonts.web.size to default) and
• had to bump all the message, completion, etc. fonts to 13pt

Things look quite ok with that. Only thing is that there is sometimes a short delay for the zoom to kick in after a page is loaded.

[prosoitos]

Another little problem with setting zoom.default: sometimes (not always) there is a little distortion of areas of the page at each keystroke while typing (for instance in GitHub or Facebook). I tried with --temp-base-dir and manually zooming in and it wasn't doing it, but since it doesn't always happen, it is hard to know whether it would eventually happen, given enough time.

[rien333]

@prosoitos What about setting something like export QT_SCALE_FACTOR=1.6 in .xinitrc? That seems to work the best for me (as well as some others)

[prosoitos]

I read #4494 and tried it out. But the resolution became really poor. Almost blurry.

Maybe there is something that I should have done beside adding export QT_SCALE_FACTOR=1.4 in my .xinitrc file??

Also, the problem of the distortion was happening in exactly the same fashion as with the zoom.default method.

The only advantage of export QT_SCALE_FACTOR is that the tooltips are scaled up. With the zoom method, I don't know how to achieve that. But overall, the poor definition made it too hard on the eyes.

Am I missing something on how to get it to work properly?

Note: I am on Arch Linux, with Xorg and EXWM.

[prosoitos]

EXWM is amazing in that it allows to live in Emacs and have real Emacs keybindings everywhere, etc. But it doesn't provide some of the sophistications that other Windows Manager have. So maybe your Windows Manager does something when you scale up so that you don't loose in resolution??

Or maybe I am a "victim" of the "strange" behaviours with non integers with QT_SCALE_FACTOR?

[prosoitos]

And as for c.qt.highdpi = True, no matter which method I choose, it has no effect whatsoever.

[rien333]

I read #4494 and tried it out. But the resolution became really poor. Almost blurry.

Weird, sorry for suggesting something you already tried. I have to say that it took a couple of tries for qutebrowser to pick up the QT_SCALE_FACTOR variable, if you haven't tried rebooting/restarting yet I recommend that. qt.highdpi = True also didn't do a whole lot for me, it's set to false in my config so I'm pretty sure it's not strictly needed to have good DPi scaling.

Something I've discovered just now is that I've also set this env variable named QT_AUTO_SCREEN_SCALE_FACTOR to something like 1.5, that could be an additional or the actually relevant variable to set.

FYI, I run Arch with bspwm (which is fairly minimal as well).

[prosoitos]

Oh! No worries!! Thank you for trying to help actually!!! 🙂

I did try to reboot, with no effect (and I actually don't think that rebooting is necessary. I think that restarting X is enough. But I did reboot, just to be sure). And I actually also tried to have QT_AUTO_SCREEN_SCALE_FACTOR in my .xinitrc file, but I thought that it had to be set to 1. So maybe that was the problem? Maybe it has to have a value matching that of QT_SCALE_FACTOR? (I am quite confused about all these variables lol).

I will give this a try before giving up on it entirely. Beside the tiny tooltips and some areas of the page bobbing up and down through some weird distortion as I type, the zoom method is not too bad. So if it is the best I can get, that'll still be fine.

[prosoitos]

I think that QT_AUTO_SCREEN_SCALE_FACTOR actually takes a true/false value. So *I think* that 1 is the correct setting. Not "1.something".

Either way, I am back to blurry screen 😞 So back to the zoom method.

[rien333]

@prosoitos note that Qt 5.14 saw some HiDPI improvements, and seemingly also some new env variables.

[prosoitos]

Ah cool! Thanks for the info @rien333. I will see if I can now get qutebrowser to work without setting a default zoom (which has been a good workaround, but increases loading time and messes up the marks)

[prosoitos]

I experimented with, for instance:

export QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough
export QT_ENABLE_HIGHDPI_SCALING=1
export QT_SCALE_FACTOR=1.4

But as with prior versions of Qt, while this scales everything perfectly to the right size, things are slightly blurry and it gives me a headache within minutes. I have a similar issue when I adjust the dpi through Xorg settings.

So I reverted to the 140% zoom. The method has its drawbacks, but at least the rendering is perfect.

[bbaserdem]

I'm on Arch; and I connect my laptop to a high-dpi display from time to time. Setting QT_ENABLE_HIGHDPI_SCALING=1 did not help with me. The other fixes in this issue do not work for me; since I change screens sometimes. (I set Xft.dpi using xrdb on autorandr hooks)

[tidux]

@bbaserdem have you tried under Wayland?

[rcorre]

I run X11 on a 4K display. I set qt.highdpi=True, and have no .Xresources or QT_* environment variables set. This worked fine on qutebrowser 2.X/qt5. With the update to qutebrowser 3.0/qt6, everything looked really small and I had to set QT_SCALE_FACTOR=2. Is that expected?

$ xrandr 
Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 32767 x 32767
HDMI-0 disconnected primary (normal left inverted right x axis y axis)
DP-0 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 630mm x 360mm
   3840x2160     60.00 + 144.00   120.00*  119.88    59.94    23.98  

$ xdpyinfo | grep -B 2 resolution
screen #0:
  dimensions:    3840x2160 pixels (633x361 millimeters)
  resolution:    154x152 dots per inch

[The-Compiler]

@rcorre That's odd! I don't think much should have changed, judging by Porting to Qt 6 | Qt 6.5. I don't really know much about how high DPI support works though - despite having a 4K screen, I don't use scaling at all (after all, 27" 4k is pretty much the same pixel density than my laptop's built-in screen with 14" FullHD).