[Webkit-unassigned] [Bug 247980] WebKitGTK seems confused about size of 1px on 283 dpi display

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=247980

--- Comment #6 from Glen Whitney <gwhitneycom5 at pobox.com> ---
The situation is further clarified by visiting https://katydecorah.com/css-ruler, under both my XFCE setup and a vanilla GNOME session.

Under XFCE, I end up with xft-dpi equal to 283, which is the physical dpi of my display, and GDK_SCALE set to 1 (no GDK-level window scaling). With these settings, visiting the css-ruler page linked above and setting the body font to 96pt causes the 1em box on the right-hand display to physically measure exactly 1 inch, and the box that is, in terms of CSS units, 1in to physically measure approximately 11/32 in. (This is roughly 1/3 in, corresponding to 96/283 being roughly 1/3.)

Under GNOME, I end up with xft-dpi equal to 96, and GDK_SCALE set to 2 (so 1 logical pixel within GDK/GTK is displayed as a 2x2 block of physical pixels, except that it does font antialiasing at full physical resolution). With these settings, visiting the css-ruler page and setting the body font to 96 pt causes the 1em and 1in CSS-sized boxes to be identical in size, and both of them to physically measure very close to 11/16 in (unsurprisingly, twice the size of the 1in box when GDK_SCALE was 1).

Thus it seems to me the root of the difficulties I am encountering is that there are two notions of pixel density, corresponding to the two types of CSS units (absolute and relative), but they are being conflated in current WebKit code for the GTK platform. It seems to me that WebKit has a responsibility that a length specified by CSS units as 1in should by default be displayed (as close as feasible) to 1 physical inch on the monitor, and for that WebKit will need to use information about the physical pixel size on the monitor on which a given page is being displayed. It also has a responsibility for fonts to appear at the scale desired/set by the user and the user's desktop environment, and for lengths specified by relative CSS units such as 1em to correspond to those font sizes. For this font scaling, WebKit will need to use the font DPI, represented in GTK by the xft-dpi setting.

The fact that my XFCE setup and GNOME sessions set the xft-dpi and GDK_SCALE so differently shows that the two concepts of pixel density described above are being treated independently and must be handled independently by WebKit to obtain the desired result that a 1in CSS dimension ends up 1 inch long on screen _and_ that a 12pt font (for example) appears at the user/environment's desired size.

To that end, I will file a pull request that renames and disambiguates the two sorts of dpi measures in existing WebKit code: WebCore::screenDPI() currently most closely corresponds to the font DPI, so I will rename it to WebCore::fontDPI() and use it exclusively for font scaling; and ScreenData.dpi corresponds to the monitor's physical pixel size, so I will rename it to ScreenData.monitorDPI and use it exclusively for scaling absolute units to their nominal sizes. These changes should resolve the issues described in this report.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240404/ba152006/attachment-0001.htm>