[webkit-changes] [WebKit/WebKit] 95b1c0: Cherry-pick 277537 at main (51f27458d0d4). https://bu...

[Glen Whitney]

  Branch: refs/heads/webkitglib/2.44
  Home:   https://github.com/WebKit/WebKit
  Commit: 95b1c087a1c04ae277bb4afda8f40c5c873d40fe
      https://github.com/WebKit/WebKit/commit/95b1c087a1c04ae277bb4afda8f40c5c873d40fe
  Author: Glen Whitney <glen at studioinfinity.org>
  Date:   2024-05-02 (Thu, 02 May 2024)

  Changed paths:
    A LayoutTests/fast/box-sizing/247980-expected.html
    A LayoutTests/fast/box-sizing/247980.html
    M Source/WebCore/accessibility/atspi/AccessibilityObjectTextAtspi.cpp
    M Source/WebCore/platform/PlatformScreen.h
    M Source/WebCore/platform/ScreenProperties.h
    M Source/WebCore/platform/graphics/gtk/SystemFontDatabaseGTK.cpp
    M Source/WebCore/platform/gtk/PlatformScreenGtk.cpp
    M Source/WebCore/platform/wpe/PlatformScreenWPE.cpp
    M Source/WebKit/UIProcess/API/glib/WebKitProtocolHandler.cpp
    M Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp

  Log Message:
  -----------
  Cherry-pick 277537 at main (51f27458d0d4). https://bugs.webkit.org/show_bug.cgi?id=272676

    [GTK] Rename screenDPI() to fontDPI() where used for font scaling.
    https://bugs.webkit.org/show_bug.cgi?id=272676

    Reviewed by Carlos Garcia Campos.

    This commit lays the groundwork for addressing DPI scaling issues under
    GTK, as described in the related bugzilla bug 247980, which seems to
    have arisen by virtue of confusion between the physical DPI of the display
    devices that WebKit is rendering on, and the GTK font scaling DPI that sets
    the desired font sizes. Hence, in line with the concerns raised in the
    references bug 272676, this commit renames WebCore::screenDPI() to
    WebCore::fontDPI() to clarify its semantics and hopefully avoid future
    similar confusions. For cases in which the underlying display density is
    needed, it adds a new WebCore::screenDPI(PlatformDisplayID) function
    to access that information, on a per-display basis.

    This commit also creates a reftest that probes the status of the referenced
    bug. Namely, the test compares a 1em box in a text size of 96px, with a
    1in box. Note the test passes as the code stands, even though when I view
    247980.html and 247980-expected.html in the minibrowser on my machine, the
    two boxes are clearly very different in size, which is one key aspect of the
    bug. Presumably, this pass occurs because the tests are run in an environment
    insulated from my actual display resolution and GTK setup. Moreover, another
    aspect of the bug is that when the two DPI measures referenced above agree,
    both boxes should measure 1 physical inch on the screen, which they currently
    do not (unless the display happens to have exactly 96 pixels per inch, low by
    today's typical specs, and unlikely to happen to be the case even when device
    scaling is employed). But I have no idea how such a condition could
    practically be tested in the WebKit test framework.

    * LayoutTests/fast/box-sizing/247980-expected.html: Added.
    * LayoutTests/fast/box-sizing/247980.html: Added.
    * Source/WebCore/accessibility/atspi/AccessibilityObjectTextAtspi.cpp:
    (WebCore::AccessibilityObjectAtspi::textAttributes const):
    * Source/WebCore/platform/PlatformScreen.h:
    * Source/WebCore/platform/ScreenProperties.h:
    * Source/WebCore/platform/graphics/gtk/SystemFontDatabaseGTK.cpp:
    (WebCore::SystemFontDatabase::platformSystemFontShorthandInfo):
    * Source/WebCore/platform/gtk/PlatformScreenGtk.cpp:
    (WebCore::fontDPI):
    (WebCore::screenDPI):
    * Source/WebCore/platform/wpe/PlatformScreenWPE.cpp:
    (WebCore::fontDPI):
    (WebCore::screenDPI):
    * Source/WebKit/UIProcess/API/glib/WebKitProtocolHandler.cpp:
    (WebKit::WebKitProtocolHandler::handleGPU):
    * Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:
    (webkit_settings_font_size_to_points):
    (webkit_settings_font_size_to_pixels):

    Canonical link: https://commits.webkit.org/277537@main

Canonical link: https://commits.webkit.org/274313.194@webkitglib/2.44


  Commit: 9864937de1cc9e250ef17b232e4ce09465c1b06a
      https://github.com/WebKit/WebKit/commit/9864937de1cc9e250ef17b232e4ce09465c1b06a
  Author: Glen Whitney <glen at studioinfinity.org>
  Date:   2024-05-02 (Thu, 02 May 2024)

  Changed paths:
    M Source/WebCore/platform/gtk/PlatformScreenGtk.cpp
    M Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp
    M Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp
    M Source/WebKit/UIProcess/API/gtk/WebKitWebViewBasePrivate.h

  Log Message:
  -----------
  Cherry-pick 278128 at main (eb01eca78d82). https://bugs.webkit.org/show_bug.cgi?id=247980

    [GTK] Correct scaling for DPI.
    https://bugs.webkit.org/show_bug.cgi?id=247980

    Reviewed by Michael Catanzaro.

    Move the scaling factor formerly in WebKitWebView.cpp (responsive to
    the xft-dpi setting) into WebKitWebViewBase.cpp, and split it into two
    scaling factors. The first, a page scaling factor, uses screenDPI to
    ensure that a length specified by a CSS unit of 1in will appear on the
    screen as one physical inch. The second, a text scaling factor, ensures
    that text specified as 96px in size will have a height on-screen as
    specified by fontDPI (which is primarily driven by the xft-dpi setting),
    in terms of the number of screen pixels taken up.

    The two scaling factors are refreshed when any one of the inputs for
    computing them changes: the GDK_SCALE factor, the xft-dpi setting, or
    the screenDPI of the device it is displayed on (say by being dragged
    to a different monitor). Throughout, at the default zoom level, a CSS
    1in dimension is kept at one physical inch.

    The scale factors are kept internal to WebKitWebViewBase (which helps
    keep GTK dependencies grouped and reduces the total code in WebKitWebView
    enclosed in `#ifdef PLATFORM(GTK)`) but made available to WebKitWebView
    so that its external interfaces can maintain zoom level 1 as the default
    zoom level, and zoom in and out from there.

    So indeed, if a user of WebKitWebView asks for a zoom level of 1.5, a
    length specified in CSS as 1in will then occupy one and a half physical
    inches on screen.

    * Source/WebCore/platform/gtk/PlatformScreenGtk.cpp:
    (WebCore::fontDPI):
    * Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:
    (webkitWebViewConstructed):
    (webkitWebViewDispose):
    (webkit_web_view_set_zoom_level):
    (webkit_web_view_get_zoom_level):
    * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:
    (_WebKitWebViewBasePrivate::_WebKitWebViewBasePrivate):
    (refreshInternalScaling):
    (webkitWebViewBaseUpdateDisplayID):
    (webkitWebViewBaseDispose):
    (webkitWebViewBaseGetScaleFactors):
    (deviceScaleFactorChanged):
    (webkitWebViewBaseCreateWebPage):
    * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBasePrivate.h:

    Canonical link: https://commits.webkit.org/278128@main

Canonical link: https://commits.webkit.org/274313.195@webkitglib/2.44


Compare: https://github.com/WebKit/WebKit/compare/bd536dfcc7d1...9864937de1cc

To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications