1916732 - Firefox Nightly mis-detects HiDPI on my X/fvwm setup after bug 1211547

Status: RESOLVED INVALID

(Core :: Widget: Gtk, defect, P2)

Description

[Chris Siebenmann]

After bug #1211547 landed in Firefox Nightly, Firefox appears to mis-detect my HiDPI settings. It may always have been happening but been masked by a minimum value of '1.0' returned by gfxPlatformGtk::GetFontScaleFactor() previously returning a minimum of 1.0. I am using X with the fvwm window manager on Linux (Fedora 40, x86_64) on a 27" HiDPI monitor. In order to get X and GTK applications to properly recognize the DPI in this non-DE environment, I have several pieces in my environment.

First I have a XSettings setup with the true DPI of the monitor,

  Gdk/UnscaledDPI 166912
  Xft/DPI 166912

And an X resouces setting of 'Xft.dpi: 163'. This is sufficient to create HiDPI text rendering but does not cause GTK to scale up UI elements. To fix that but not make text huge, I set environment variables:

  GDK_SCALE=2
  GDK_DPI_SCALE=0.5

This is supposed to scale GDK to 2 but then scale text down again, so that it remains at the Xft size (which is correct). This behavior works in normal GTK applications.

Without these environment variables set, GetFontScaleDPI() sees my DPI as 163 (but Firefox is then gigantic).

Comment 1

[Matthijs Velsink [:velsinki]]

I couldn't comment on bug 1211547 as I don't have editbugs privileges, but I am the one who submitted that patch.

That GetFontScaleDPI() returns 82 makes sense, as it's the rounded 0.5 * 163 (see https://gitlab.gnome.org/GNOME/gtk/-/blame/7d1b9bf2802fc3d8160f8483e1adc1535aac5b89/gdk/x11/xsettings-client.c#L500) . Your font scaling compared to a 96 DPI baseline will then be around 0.854 (82/96), which is indeed only possible with my patch.

You commented that you set your layout.css.devPixelsPerPx to 1.7. What's the reason for that particular value? I'm not sure how GetFontScaleDPI() is used, but if that is used for all positioning, a layout.css.devPixelsPerPx value of 2 makes more sense to me.

Comment 2

[Chris Siebenmann]

In my environment (with normal environment variables), the Firefox default results from layout.css.devPixelsPerPx (with it set to the '-1' default) is about equal to 2. I turned mine down to 1.7 because I found the font sizes at 2 to be a bit too big for my taste.

Comment 3

[Matthijs Velsink [:velsinki]]

But maybe I'm misunderstanding the issue here, but wasn't the font slightly too big because it was reporting a scaling of 1? Now with 0.85, it should have roughly the same size as what you had before if you put devPixelsPerPx to 2 now.

Comment 4

[Chris Siebenmann]

Clearing devPixelsPerPx does reset my size to almost exactly what it was before this change. But that suggests that anyone in a similar situation without a devPixelsPerPx is going to see their Firefox (text) sizes shrink after this change, because previously the floor of Firefox's internal DPI was 1.0.

Comment 5

[Matthijs Velsink [:velsinki]]

On Wayland at least, this should be the intended result I think. The text-scaling-factor is directly mapped to the dpi with a factor 96 (https://gitlab.gnome.org/GNOME/gtk/-/blob/40fbad61575b0599998ba4751ee97cb99838d815/gdk/wayland/gdkscreen-wayland.c#L304) and therefore the only way to get a dpi below 96 is if the scaling factor was set below 1.

Although GDK_DPI_SCALE also does something on Wayland, it's not recommended to use that as it doesn't do anything for GTK4 but text-scaling-factor does.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1211547

:jhorak, since you are the author of the regressor, bug 1211547, could you take a look?

For more information, please visit BugBot documentation.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Yeah, this seems like Firefox is detecting HiDPI correctly, it's just that you were depending on the previous behavior (by setting devPixelsPerPx)

Comment 8

[Chris Siebenmann]

The more I think about this the more uncertain I am. Based on the description of the environment variables I'm using, from https://docs.gtk.org/gtk3/x11.html, it appears that GDK_SCALE plus GDK_DPI_SCALE should result in gdk_screen_get_resolution() returning my true 163 DPI. Obviously it does not; it applies GDK_DPI_SCALE but not GDK_SCALE, and presumably text rendering is then scaled by GDK_SCALE in the backend somewhere. The whole situation seems to be kind of messy and I'm not sure what DPI Firefox should be getting in order to work right.

Comment 9

[Matthijs Velsink [:velsinki]]

In general, gdk_screen_get_resolution() is meant for fonts only. It will return the font resolution (i.e. DPI) that GTK3 is currently using to scale fonts. Normally (for X11), this just follows Xft.dpi. However, that does not affect the rest of the UI, which is indeed why you need GDK_SCALE. But that also scales fonts, which is why GDK_DPI_SCALE can be used to just (down)scale fonts separate from UI.

This is just the architecture of GTK3, see it as if GDK_SCALE=2 effectively still uses 1x1 pixels internally, but physically they are 2x2. So internally, it would still scale fonts with 163 DPI, which is now effectively 326, hence the need for GDK_DPI_SCALE=0.5, which makes the internal DPI 82.

Firefox essentially doesn't know about GDK_SCALE=2. If it asks for something 10 pixels wide, GTK will scale that to 20 pixels. This is also why Firefox needs to assume 82 DPI. Note that website rendering doesn't use GTK3, which is why settings like devPixelsPerPx exist, and Firefox has functions like GetFontScaleDPI(), so that Firefox's own drawing can match the rest of the UI.

On Wayland, none of the GTK3 env variables are really a thing, as the GTK scale gets pulled from the monitor, and the correctly named dconf setting text-scaling-factor is used to scale fonts relative to 96 DPI.

So I do think this is as intended and not a regression. Besides, whatever gdk_screen_get_resolution() returns is also what all other GTK3/4 apps are using on your desktop, so this should match better for most users.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Hey stransky, given the above, is this a WONTFIX / INVALID?

Comment 11

[Martin Stránský [:stransky] (ni? me)]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #10)

Hey stransky, given the above, is this a WONTFIX / INVALID?

Emilio may be better person here but yeah, sounds reasonable.