[Webkit-unassigned] [Bug 274351] Could WebKitGTK WebCore::fontDPI() depend on monitor (PlatformDisplayID)?

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from Glen Whitney <gwhitneycom5 at pobox.com> ---
(In reply to Michael Catanzaro from comment #3)

> I guess it's the window system concept of a display, like
> wayland-0 or :0? 

I think so, too.

> Anyway, I suspect this is probably not actually terribly relevant for the
> purposes of this issue.

I agree.

> OK, I didn't intend "don't consider screenDPI at all" but rather "treat
> fontDPI as a multiplier to the screenDPI rather than as a fonts-only
> setting." So I see now that refreshInternalScaling in WebKitWebViewBase.cpp
> is not considering screenDPI at all. Why not do something like:
> 
> double newPageScale = WebCore::fontDPI() /
> WebCore::screenDPI(webViewBase->priv->displayID);
> 
> and use 96. as the fallback only if WebCore::screenDPI would return 0? I
> assume I'm either misunderstanding or missing something important?

I am interpreting fontDPI as the requested number of device pixels that a 72pt font should take up. As such, the current formula `newPageScale = WebCore::fontDPI()/96` implements that, since the default Cairo scaling is to use 96 device pixels for a 72pt font.

Consider what your formula would do on a precisely 192 dpi screen: presumably fontDPI() would return 192 and by assumption screenDPI would return 192, so newPageScale would be 1, and the default Cairo scaling would be used, leading to fonts half the ideal physical size on the screen (a 72pt font would take up 96 pixels and so have an em-length of half an inch in actual physical appearance, as opposed to one inch as desired).

Basically, for 72pt fonts to be rendered at the specified number of device pixels (presuming that is indeed the meaning of xft-dpi), the product of page scale and text scale _must_ be fontDPI()/96. If you always want layouts to look as "designed", then text scale must be 1, so we are left with the formula as it stands. Hence, the only room I could see to take account of differing screenDPI()s on different monitors is to assume that the fontDPI() only pertains to one specific monitor, and scale the others by their ratios of screenDPI(). The question is then which monitor? Back in GTK3 there was an obvious choice: it had a notion of a primary monitor. As far as I can see, that notion was entirely removed in GTK4 (but would love expert verification of that), but since WebKitGTK still has its own notion of primary display, we could just use that one.

One the other hand, given that GTK specifically removed the notion of primary monitor, it makes the specific association of fontDPI with any one particular monitor seem a bit sketchy. So I suppose an alternative would be to take some mean DPI of all the screens (not sure if it should be the arithmetic, geometric, or harmonic mean, offhand) and use newPageScale = (fontDPI()/96)*(screenDPI()/meanDPI). Then perhaps no one screen would use exactly fontDPI() device pixels for a 72pt font, but they would all vary around that many pixels and average out to fontDPI() pixels over all of the screens.

Hopefully I've expressed these things clearly enough for you to take stock of the situation and decide if you think it's worth making any further change. I am happy to try to answer any other questions you may have.

-- 
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/20240520/3140bb0c/attachment-0001.htm>