Bug 247980 – WebKitGTK seems confused about size of 1px on 283 dpi display

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Glen Whitney]

Created attachment 463553 [details]
webkitgtk.org in MiniBrowser

I already posted this situation at https://bugs.webkit.org/show_bug.cgi?id=131347 in an effort not to needlessly create new issues, but was advised there to open a new item. So here goes.

I am running WebKitGTK 2.38.2 on a 283 dpi laptop with OpenSUSE Tumbleweed and their latest build of xfce 4.17. Out of the box, the webkitgtk3 MiniBrowser renders webkitgtk.org with a very narrow main block (see first screenshot attached) whereas Firefox renders it as expected (see the second screenshot attached, which I will do immediately after filing since I don't see a way to attach more than one file initially).

Note the fonts appear basically reasonably sized in both cases, but the MiniBrowser seems to think that 960px (the width of that main block) is a very small fraction of the screen. But the screen is 13" wide, so it should be about 3/4 of the screen width, which is just about what it is in Firefox. Is there a way to tell WebkitGTK that a px should be 3 physical pixels? (I have tried GDK_SCALE=3 -- with that setting, the main block indeed comes out the roughly correct fraction of the screen, but the fonts are all way too huge, see the third screenshot attached. It would be desirable for WebkitGTK to simultaneously get px measurements correct and fonts the appropriate sizes.)

In particular, these problems make html email more or less unreadable in Evolution, which would otherwise be my mail reader of choice. Milan Crha, a developer/maintainer of Evolution, suggested that it could be useful for me to post at least the top of the webkit://gpu information from the MiniBrowser. So it's incorporated below. It seems as though webkitgtk has the correct information for every characteristic shown, which makes the display issues shown here appear to me to be more like a bug than misconfiguration, especially given that other browsers are fine. Thanks for your thoughts/help.

------------------------- webkit://gpu results follow -------------------
Version Information
WebKit version
WebKitGTK 2.38.2 (tarball)
Operating system
Linux 6.0.8-1-default #1 SMP PREEMPT_DYNAMIC Fri Nov 11 08:02:50 UTC 2022 (1579d93) x86_64
Desktop
XFCE
Cairo version
1.17.6 (build) 1.17.6 (runtime)
GStreamer version
1.20.4 (build) GStreamer 1.20.4 (runtime)
GTK version
3.24.34 (build) 3.24.34 (runtime)
Display Information
Type
X11
Screen geometry
0,0 3840x2400
Screen work area
0,0 3840x2400
Depth
24
Bits per color component
8
DPI
283.00
Hardware Acceleration Information
Policy
always
WebGL enabled
Yes
API
OpenGL
Native interface
GLX
GL_RENDERER
Mesa Intel(R) Graphics (ADL GT2)
GL_VENDOR
Intel
GL_VERSION
4.6 (Core Profile) Mesa 22.2.3
.... [remainder cut]

[Glen Whitney]

Created attachment 463554 [details]
webkitgtk.org in Firefox

[Glen Whitney]

Created attachment 463555 [details]
webkitgtk.org in MiniBrowser with GDK_SCALE=3

[Glen Whitney]

Eighteen months later, just checking in to say that the situation is just equally bad in the updated similar environment, described by the following results of webkit://gpu; I have not attached new screenshots as they are essentially identical.

Thanks for any thoughts, pointers, or attention you can give this situation.

----
{
    "Version Information": {
        "WebKit version": "WebKitGTK 2.44.0 (tarball)",
        "Operating system": "Linux 6.8.1-1-default #1 SMP PREEMPT_DYNAMIC Tue Mar 19 07:32:20 UTC 2024 (d922afa) x86_64",
        "Desktop": "XFCE",
        "Cairo version": "1.18.0 (build) 1.18.0 (runtime)",
        "GStreamer version": "1.24.0 (build) GStreamer 1.24.0 (runtime)",
        "GTK version": "3.24.41 (build) 3.24.41 (runtime)"
    },
    "Display Information": {
        "Identifier": "1",
        "Type": "X11",
        "Screen geometry": "0,0 3840x2400",
        "Screen work area": "0,0 3840x2400",
        "Depth": "24",
        "Bits per color component": "8",
        "DPI": "283",
        "VBlank type": "Timer",
        "VBlank refresh rate": "60Hz",
        "DRM Device": "/dev/dri/card0",
        "DRM Render Node": "/dev/dri/renderD128"
    },
    "API": "OpenGL (libepoxy)",
    "Hardware Acceleration Information": {
        "Policy": "always",
        "WebGL enabled": "Yes",
        "Renderer": "DMABuf (Supported buffers: Hardware, Shared Memory)",
        "Native interface": "None"
    },
---------- (remainder cut)

[Glen Whitney]

Some more information, however: the scaling issues appear to apply to many (maybe all) "absolute" CSS units and not to the "relative" CSS units. For example, if I copy the html/css source of webkitgtk.org and change all occurrences of `px` units to `in` units, dividing the numerical values by 96, it produces essentially the identical appearance as originally shown; whereas if I change all `px` to `rem`, dividing the numerical values by 16 (corresponding to the default root font size of 16px), the page looks as desired/expected (see screenshot below). Hopefully this can help track down the issue or suggest a compensatory setting/workaround I might use. Thanks.

[Glen Whitney]

Created attachment 470737 [details]
clone of webkitgtk.org modified to have all dimensions in rem

[Glen Whitney]

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.

[Michael Pujos]

I am observing something that I think is similar with MiniBrowser (and other WebKitGTK browsers such as Nyxt) using WebKitGTK 2.44.0 on a laptop with a 17.3" 4K panel (254 physical dpi) running on i3 Window Manager.

On that setup, I use Xft.dpi: 240 (for 2.5x font scaling) and GDK_DPI_SCALE=0.5, GDK_SCALE=2 (2x GTK UI scaling).
It works fine with all my programs except WebKitGTK resulting in huge font rendering and rendering bugs (screenshot: https://imgur.com/a/yXmBuVA), as if Xft scaling and GTK scaling were combined.

The only combination of these 3 parameters that I found render properly (without too big fonts nor UI rendering issues) is to set Xft.dpi: 96 (with GDK_DPI_SCALE=0.5, GDK_SCALE=2), except that fonts are a bit too small (at 2x scaling instead of 2.5).

IIRC, WebKitGTK before 2.44.0 did not have this issue where Xft.dpi and GDK env variables seems to be conflicting.

[Glen Whitney]

Michael, thanks for your report. I just tested the following two commands with what will be my proposed patch to address this bug:

GDK_SCALE=1 GDK_DPI_SCALE=1 /usr/libexec/libwebkit2gtk-4_1-0/MiniBrowser

and

GDK_SCALE=2 GDK_DPI_SCALE=0.5 /usr/libexec/libwebkit2gtk-4_1-0/MiniBrowser

and the current behavior is that the default text font in ordinary webpage text content comes out twice as large in the second case. I don't use either of the GDK_xx_SCALE environment variables, so I am not sure if this is the expected behavior, or if you would expect the font in ordinary webpage text content to be the same size in the latter case. Please advise so I can adjust my PR if need be before it is resubmitted. Thanks!

[Michael Pujos]

First, I tested MiniBrowser with v2.42.5 and it has the same HiDpi scaling issues than v2.44.

With the current situation I get correct scaling for font and UI without rendering bugs (for example, the "latest news" panel on webkitgtk.org being truncated on the right) with the combination of: 

"Xft.dpi: 96" (no font scaling)
GDK_SCALE=2 GDK_DPI_SCALE=0.5  (2x GTK UI scaling)


Any other value for Xft.dpi (I use 240 normally) combined with whatever other values of GDK_SCALE and GDK_DPI_SCALE result in either fonts not being the proper size and/or broken rendering in web pages and UI (GTK widgets).

The GDK_ env variables are a GTK thing so scale it. Not sure if WebKitGTK ever make use of them in its code. It would be a good idea to grep the whole code to check if it does.

Anyway, if your patch fixes the Xft.dpi issue where setting a value other than 96 works fine (on my setup: "Xft.dpi: 240" GDK_SCALE=1 GDK_DPI_SCALE=1 (or both of these env variables being unset which is the same thing)), that's OK for me.

Though proper HiDpi handling is a complex thing and relevant WebKit devs should   give their opinion on the best way to handle it. Especially since many users may have GDK_SCALE and GDK_DPI_SCALE defined in their global environment for scaling GTK apps, as they are needed for proper scaling in other GTK programs (such as Firefox).

[Michael Catanzaro]

(In reply to Michael Pujos from comment #9) 
> Though proper HiDpi handling is a complex thing and relevant WebKit devs
> should   give their opinion on the best way to handle it.

I'm afraid you and Glen are most likely now our resident experts on hidpi.

[Michael Catanzaro]

Pull request link: https://github.com/WebKit/WebKit/pull/26938

[Glen Whitney]

OK, well, testing various settings of GDK_SCALE and GDK_DPI_SCALE with `gnome-text-editor` (which is built with GTK4) and `shotwell` (still built with GTK3), it appears that GDK_DPI_SCALE has no effect under GTK4, and indeed, I cannot find any documentation of it or any api call that would seem to relate to it in the GTK4 docs.

On the other hand, it appears that the intended behavior under GTK3 is that GDK_DPI_SCALE should scale all fonts (but nothing else). So I will adjust the proposed patch to have that behavior, once the preliminary PR https://github.com/WebKit/WebKit/pull/26954 has been acted upon.

I have been using a HiDPI display for several years but I am definitely no GTK expert, so if the maintainers have anyone else to bounce this plan off of, it would be appreciated. But I _think_ I now have all of the relevant settings and what they should do clear in my head.

[Michael Pujos]

Grepping into the GTK4 source code, GDK_SCALE is still used on Xorg only (to override scaling factor otherwise determined by other means) while GDK_DPI_SCALE is not used anymore.

Here's its documentation:


"Must be set to an integer, typically 2. If set, GDK will scale all
windows by the specified factor. Scaled output is meant to be used on
high-dpi displays. Normally, GDK will pick up a suitable scale factor
for each monitor from the display system. This environment variable
allows to override that."

[Michael Catanzaro]

Presumably gdk_surface_get_scale() will tell us the scale we should use? (Or gdk_surface_get_scale_factor() for GTK prior to 4.12.)

[Glen Whitney]

Yes, that's the overall device scale that blows up everything, not anything font-specific. It's pretty uniformly handled in GTK3 and GTK4, and I believe I am addressing it reasonably in both versions of the toolkit.

[EWS]

Committed 278128@main (eb01eca78d82): <https://commits.webkit.org/278128@main>

Reviewed commits have been landed. Closing PR #26938 and removing active labels.

[Philippe Normand]

(In reply to EWS from comment #16)
> Committed 278128@main (eb01eca78d82):
> <https://commits.webkit.org/278128@main>
> 
> Reviewed commits have been landed. Closing PR #26938 and removing active
> labels.

This patch made everything too big, in Wayland, GTK3 and GTK4 builds...

[Philippe Normand]

Created attachment 471374 [details]
MiniBrowser too big

[Philippe Normand]

Created attachment 471375 [details]
MiniBrowser OK

[Michael Catanzaro]

I see it's bigger now... but is it possible that everything was previously too small? Try holding a tape measure near your monitor and viewing https://katydecorah.com/css-ruler/ and look at the purple bars.

[Philippe Normand]

(In reply to Michael Catanzaro from comment #20)
> I see it's bigger now... but is it possible that everything was previously
> too small? Try holding a tape measure near your monitor and viewing
> https://katydecorah.com/css-ruler/ and look at the purple bars.

I compared with the Chrome output and same window size on another site, and it's definitely bigger than it should.

[Philippe Normand]

(In reply to Michael Catanzaro from comment #20)
> I see it's bigger now... but is it possible that everything was previously
> too small? Try holding a tape measure near your monitor and viewing
> https://katydecorah.com/css-ruler/ and look at the purple bars.

I don't think that's a good benchmark? the "1cm" square measures 6mm here, both in Chrome and Ephy. Is 1cm in CSS supposed to be 1cm in the real world?

[Carlos Garcia Campos]

Reopened Bugzilla.
Broke font rendering in some cases, tracking revert in https://bugs.webkit.org/show_bug.cgi?id=274075.

[Glen Whitney]

(1) My apologies for any trouble my efforts so far have caused -- I am solely attempting to improve WebKitGTK, which currently produces unusable web page renderings on my Xwindows setup as described above (and which setup works reasonably with other browsers).

(2) As to whether the css-ruler linked is a reasonable benchmark, the [CSS standard](https://www.w3.org/TR/css-values-3/#lengths) for absolute unit sizes says that the canonical unit is the px, and the px is defined as *either* 1/96 of an inch (crazy to have a global standard based on idiosyncratic US units) *or* the distance that subtends an angle of 0.0213 degrees at the expected viewing distance of the device. For the nominal "arm's length" viewing distance (28 inches), the two definitions coincide. It therefore seemed quite reasonable to scale the WebKitGTK rendering so that 1cm would indeed be 1 physical cm, as that is standard-compliant under the first definition and under both definitions for a typical desktop. Hence that is what the now-reverted PR did.

Aside: I do acknowledge that scaling was not the standard's "recommended" behavior on smartphones, which have a significantly lower expected viewing distance, [typically 12-14 inches](https://www.w3.org/TR/css-values-3/#lengths), so a CSS 1cm box "should" be rendered at approximately 4-5 mm on mobile. I wasn't sure how to differentiate the screen type, nor of the extent to which WebKitGTK expected to produce ideal results on a mobile device; note tying absolute dimensions to equal physical lengths is always standard-compliant, although it is not the behavior "recommended" by the standard for mobile devices or for screens expected to be viewed at farther than arms length (such as electronic billboards). Also, since the current behavior on hi-dpi desktops is so far from standards-compliant, getting to at least some compliant state overall seemed like a win.

(3) Finally, I would of course like the opportunity to make a revised PR to resolve this issue, and clearly it would need to be one that does not cause the difficulties referred to in issue https://bugs.webkit.org/show_bug.cgi?id=274075  -- however, there is not any detail in that issue: it simply states "Broke font rendering in some cases" but does not give any information as to what cases or how to reproduce or how to know what is correct font rendering in these cases or how to test. Please could someone on this discussion provide guidance on the actual requirements/constraints on a fix to this issue, how to test it, and on how to decide the screen dimension for 1px (or equivalently for 1cm, as the two are strictly tied to each other by the CSS standard)? The current mechanism is producing unusably tiny screen dimensions on a display with 283 physical pixels per inch, and XWindows correctly reporting the resolution and the display size. Hence some fix is needed, and I am happy to submit it, but at the moment I don't have the information necessary for a potentially successful PR.

Thank you so much!

[Michael Catanzaro]

This also introduced bug #274083 ("Sides of buttons are cut off on GitLab") which I incorrectly blamed on Skia. I do not know what's wrong with the buttons.

(In reply to Glen Whitney from comment #24)
> I wasn't sure how to differentiate the screen type, nor of the extent to which WebKitGTK expected to produce ideal results on a mobile device;

It's expected to work on both mobile and desktop. hostnamed has a chassis type field that can be used to detect mobile devices; however, it's not accessible in the web process sandbox, so we'd need to create a chassis type portal to access it. It's probably better to avoid altering behavior based on chassis type and instead change the behavior based on screen size instead. (Normally I would say "window size" rather than screen size, but for the purposes of this issue, sounds like screen size is really what matters.)

> (3) Finally, I would of course like the opportunity to make a revised PR to
> resolve this issue, and clearly it would need to be one that does not cause
> the difficulties referred to in issue
> https://bugs.webkit.org/show_bug.cgi?id=274075  -- however, there is not any
> detail in that issue: it simply states "Broke font rendering in some cases"
> but does not give any information as to what cases or how to reproduce or
> how to know what is correct font rendering in these cases or how to test.

I've also asked for more info here, but so far all I've heard is "too big" which is not very precise. I haven't noticed any size changes myself other than the issue with the buttons.

If Firefox and Chrome behave consistently, then it'd be pragmatic to match whatever they do.

[Philippe Normand]

Well look at the screenshots? The down arrows are clearly too big, aren't they? And the + sign boxes too, the + is not centered at all (that looks like an issue without this patch though but due to the additional spacing it's now worse). 

Not sure what else you need :)

[Glen Whitney]

Well, all of those things look fine for me; can you show your webkit://gpu output and I can try to mock up your setup as best as I can to try to reproduce? Thanks so much.

[Philippe Normand]

{
    "Version Information": {
        "WebKit version": "WebKitGTK 2.45.1 (278698@main)",
        "Operating system": "Linux 6.8.9-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May  2 18:59:06 UTC 2024 x86_64",
        "Desktop": "GNOME",
        "GStreamer version": "1.24.2 (build) GStreamer 1.24.2 (runtime)",
        "GTK version": "3.24.41 (build) 3.24.41 (runtime)"
    },
    "Display Information": {
        "Identifier": "1",
        "Type": "Wayland",
        "Screen geometry": "0,0 1920x1080",
        "Screen work area": "0,0 1920x1080",
        "Depth": "32",
        "Bits per color component": "8",
        "Font Scaling DPI": "96",
        "Screen DPI": "143.6604169978542",
        "VBlank type": "DRM",
        "VBlank refresh rate": "59Hz",
        "DRM Device": "/dev/dri/card1",
        "DRM Render Node": "/dev/dri/renderD128"
    },
    "API": "OpenGL (libepoxy)",
    "Hardware Acceleration Information": {
        "Policy": "always",
        "WebGL enabled": "Yes",
        "Renderer": "DMABuf (Supported buffers: Hardware, Shared Memory)",
        "Buffer format": "DMA-BUF: XR24 (INTEL_Y_TILED_CCS) [Rendering]",
        "Native interface": "EGL",
        "GL_RENDERER": "Mesa Intel(R) UHD Graphics 630 (CFL GT2)",
        "GL_VENDOR": "Intel",
        "GL_VERSION": "4.6 (Core Profile) Mesa 24.0.5",
        "GL_SHADING_LANGUAGE_VERSION": "4.60",
        "GL_EXTENSIONS": "GL_3DFX_texture_compression_FXT1 GL_AMD_conservative_depth GL_AMD_depth_clamp_separate GL_AMD_draw_buffers_blend GL_AMD_gpu_shader_int64 GL_AMD_multi_draw_indirect GL_AMD_performance_monitor GL_AMD_pinned_memory GL_AMD_query_buffer_object GL_AMD_seamless_cubemap_per_texture GL_AMD_shader_stencil_export GL_AMD_shader_trinary_minmax GL_AMD_texture_texture4 GL_AMD_vertex_shader_layer GL_AMD_vertex_shader_viewport_index GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ARB_ES2_compatibility GL_ARB_ES3_1_compatibility GL_ARB_ES3_2_compatibility GL_ARB_ES3_compatibility GL_ARB_arrays_of_arrays GL_ARB_base_instance GL_ARB_blend_func_extended GL_ARB_buffer_storage GL_ARB_clear_buffer_object GL_ARB_clear_texture GL_ARB_clip_control GL_ARB_compressed_texture_pixel_storage GL_ARB_compute_shader GL_ARB_compute_variable_group_size GL_ARB_conditional_render_inverted GL_ARB_conservative_depth GL_ARB_copy_buffer GL_ARB_copy_image GL_ARB_cull_distance GL_ARB_debug_output GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_derivative_control GL_ARB_direct_state_access GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_draw_indirect GL_ARB_draw_instanced GL_ARB_enhanced_layouts GL_ARB_explicit_attrib_location GL_ARB_explicit_uniform_location GL_ARB_fragment_coord_conventions GL_ARB_fragment_layer_viewport GL_ARB_fragment_shader GL_ARB_fragment_shader_interlock GL_ARB_framebuffer_no_attachments GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_get_program_binary GL_ARB_get_texture_sub_image GL_ARB_gl_spirv GL_ARB_gpu_shader5 GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader_int64 GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_indirect_parameters GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_internalformat_query2 GL_ARB_invalidate_subdata GL_ARB_map_buffer_alignment GL_ARB_map_buffer_range GL_ARB_multi_bind GL_ARB_multi_draw_indirect GL_ARB_occlusion_query2 GL_ARB_parallel_shader_compile GL_ARB_pipeline_statistics_query GL_ARB_pixel_buffer_object GL_ARB_point_sprite GL_ARB_polygon_offset_clamp GL_ARB_post_depth_coverage GL_ARB_program_interface_query GL_ARB_provoking_vertex GL_ARB_query_buffer_object GL_ARB_robust_buffer_access_behavior GL_ARB_robustness GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_seamless_cubemap_per_texture GL_ARB_separate_shader_objects GL_ARB_shader_atomic_counter_ops GL_ARB_shader_atomic_counters GL_ARB_shader_ballot GL_ARB_shader_bit_encoding GL_ARB_shader_clock GL_ARB_shader_draw_parameters GL_ARB_shader_group_vote GL_ARB_shader_image_load_store GL_ARB_shader_image_size GL_ARB_shader_objects GL_ARB_shader_precision GL_ARB_shader_stencil_export GL_ARB_shader_storage_buffer_object GL_ARB_shader_subroutine GL_ARB_shader_texture_image_samples GL_ARB_shader_texture_lod GL_ARB_shader_viewport_layer_array GL_ARB_shading_language_420pack GL_ARB_shading_language_include GL_ARB_shading_language_packing GL_ARB_spirv_extensions GL_ARB_stencil_texturing GL_ARB_sync GL_ARB_tessellation_shader GL_ARB_texture_barrier GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_buffer_range GL_ARB_texture_compression_bptc GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map_array GL_ARB_texture_filter_anisotropic GL_ARB_texture_float GL_ARB_texture_gather GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_query_levels GL_ARB_texture_query_lod GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_rgb10_a2ui GL_ARB_texture_stencil8 GL_ARB_texture_storage GL_ARB_texture_storage_multisample GL_ARB_texture_swizzle GL_ARB_texture_view GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_transform_feedback_instanced GL_ARB_transform_feedback_overflow_query GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_attrib_64bit GL_ARB_vertex_attrib_binding GL_ARB_vertex_buffer_object GL_ARB_vertex_shader GL_ARB_vertex_type_10f_11f_11f_rev GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_ATI_blend_equation_separate GL_ATI_texture_float GL_EXT_EGL_image_storage GL_EXT_EGL_sync GL_EXT_abgr GL_EXT_blend_equation_separate GL_EXT_debug_label GL_EXT_demote_to_helper_invocation GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_memory_object GL_EXT_memory_object_fd GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_pixel_buffer_object GL_EXT_polygon_offset_clamp GL_EXT_provoking_vertex GL_EXT_semaphore GL_EXT_semaphore_fd GL_EXT_shader_framebuffer_fetch GL_EXT_shader_framebuffer_fetch_non_coherent GL_EXT_shader_integer_mix GL_EXT_shader_samples_identical GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_sRGB GL_EXT_texture_sRGB_R8 GL_EXT_texture_sRGB_decode GL_EXT_texture_shadow_lod GL_EXT_texture_shared_exponent GL_EXT_texture_snorm GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_EXT_vertex_attrib_64bit GL_IBM_multimode_draw_arrays GL_INTEL_blackhole_render GL_INTEL_conservative_rasterization GL_INTEL_performance_query GL_INTEL_shader_atomic_float_minmax GL_INTEL_shader_integer_functions2 GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_KHR_context_flush_control GL_KHR_debug GL_KHR_no_error GL_KHR_parallel_shader_compile GL_KHR_robust_buffer_access_behavior GL_KHR_robustness GL_KHR_texture_compression_astc_ldr GL_KHR_texture_compression_astc_sliced_3d GL_MESA_framebuffer_flip_y GL_MESA_pack_invert GL_MESA_shader_integer_functions GL_MESA_texture_const_bandwidth GL_MESA_texture_signed_rgba GL_NV_alpha_to_coverage_dither_control GL_NV_compute_shader_derivatives GL_NV_conditional_render GL_NV_copy_image GL_NV_depth_clamp GL_NV_fragment_shader_interlock GL_NV_packed_depth_stencil GL_NV_texture_barrier GL_OES_EGL_image GL_S3_s3tc",
        "EGL_VERSION": "1.5",
        "EGL_VENDOR": "Mesa Project",
        "EGL_EXTENSIONS": "EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_device EGL_EXT_explicit_device EGL_EXT_platform_wayland EGL_KHR_platform_wayland EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_EXT_platform_xcb EGL_MESA_platform_gbm EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync EGL_EXT_buffer_age EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_EXT_present_opaque EGL_EXT_query_reset_notification_strategy EGL_EXT_swap_buffers_with_damage EGL_IMG_context_priority EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_context_flush_control EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image_base EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_KHR_swap_buffers_with_damage EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_gl_interop EGL_MESA_image_dma_buf_export EGL_MESA_query_driver EGL_WL_bind_wayland_display EGL_WL_create_wayland_buffer_from_image "
    },
    "Hardware Acceleration Information (Render process)": {
        "Platform": "GBM",
        "DRM version": "i915 (Intel Graphics) 1.6.0. 20230929",
        "GL_RENDERER": "Mesa Intel(R) UHD Graphics 630 (CFL GT2)",
        "GL_VENDOR": "Intel",
        "GL_VERSION": "OpenGL ES 3.2 Mesa 24.0.5",
        "GL_SHADING_LANGUAGE_VERSION": "OpenGL ES GLSL ES 3.20",
        "GL_EXTENSIONS": "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_half_float GL_EXT_draw_instanced GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_OES_depth_texture GL_AMD_performance_monitor GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_NV_conditional_render GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_NV_pack_subimage GL_NV_texture_barrier GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_OES_viewport_array GL_ANGLE_pack_reverse_row_order GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_EXT_occlusion_query_boolean GL_EXT_robustness GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_APPLE_sync GL_EXT_draw_buffers GL_EXT_instanced_arrays GL_EXT_map_buffer_range GL_KHR_debug GL_KHR_robustness GL_KHR_texture_compression_astc_ldr GL_NV_generate_mipmap_sRGB GL_NV_pixel_buffer_object GL_OES_depth_texture_cube_map GL_OES_required_internalformat GL_OES_surfaceless_context GL_EXT_color_buffer_float GL_EXT_debug_label GL_EXT_sRGB_write_control GL_EXT_separate_shader_objects GL_EXT_shader_framebuffer_fetch GL_EXT_shader_group_vote GL_EXT_shader_implicit_conversions GL_EXT_shader_integer_mix GL_EXT_tessellation_point_size GL_EXT_tessellation_shader GL_INTEL_conservative_rasterization GL_INTEL_performance_query GL_ANDROID_extension_pack_es31a GL_EXT_base_instance GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_copy_image GL_EXT_draw_buffers_indexed GL_EXT_draw_elements_base_vertex GL_EXT_gpu_shader5 GL_EXT_polygon_offset_clamp GL_EXT_primitive_bounding_box GL_EXT_render_snorm GL_EXT_shader_io_blocks GL_EXT_texture_border_clamp GL_EXT_texture_buffer GL_EXT_texture_cube_map_array GL_EXT_texture_norm16 GL_EXT_texture_view GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_KHR_context_flush_control GL_KHR_robust_buffer_access_behavior GL_NV_image_formats GL_NV_shader_noperspective_interpolation GL_OES_copy_image GL_OES_draw_buffers_indexed GL_OES_draw_elements_base_vertex GL_OES_gpu_shader5 GL_OES_primitive_bounding_box GL_OES_sample_shading GL_OES_sample_variables GL_OES_shader_io_blocks GL_OES_shader_multisample_interpolation GL_OES_tessellation_point_size GL_OES_tessellation_shader GL_OES_texture_border_clamp GL_OES_texture_buffer GL_OES_texture_cube_map_array GL_OES_texture_stencil8 GL_OES_texture_storage_multisample_2d_array GL_OES_texture_view GL_EXT_blend_func_extended GL_EXT_buffer_storage GL_EXT_float_blend GL_EXT_geometry_point_size GL_EXT_geometry_shader GL_EXT_shader_samples_identical GL_EXT_texture_sRGB_R8 GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d GL_NV_fragment_shader_interlock GL_OES_EGL_image_external_essl3 GL_OES_geometry_point_size GL_OES_geometry_shader GL_OES_shader_image_atomic GL_EXT_clear_texture GL_EXT_clip_cull_distance GL_EXT_disjoint_timer_query GL_EXT_texture_compression_s3tc_srgb GL_MESA_shader_integer_functions GL_EXT_clip_control GL_EXT_color_buffer_half_float GL_EXT_memory_object GL_EXT_memory_object_fd GL_EXT_semaphore GL_EXT_semaphore_fd GL_EXT_texture_compression_bptc GL_EXT_texture_mirror_clamp_to_edge GL_KHR_parallel_shader_compile GL_NV_alpha_to_coverage_dither_control GL_EXT_EGL_image_storage GL_EXT_shader_framebuffer_fetch_non_coherent GL_EXT_texture_shadow_lod GL_INTEL_blackhole_render GL_MESA_framebuffer_flip_y GL_NV_compute_shader_derivatives GL_EXT_demote_to_helper_invocation GL_EXT_depth_clamp GL_EXT_texture_query_lod GL_MESA_sampler_objects GL_MESA_bgra GL_MESA_texture_const_bandwidth ",
        "EGL_VERSION": "1.5",
        "EGL_VENDOR": "Mesa Project",
        "EGL_EXTENSIONS": "EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_device EGL_EXT_explicit_device EGL_EXT_platform_wayland EGL_KHR_platform_wayland EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_EXT_platform_xcb EGL_MESA_platform_gbm EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync EGL_EXT_buffer_age EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_EXT_query_reset_notification_strategy EGL_IMG_context_priority EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_context_flush_control EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_gl_interop EGL_MESA_image_dma_buf_export EGL_MESA_query_driver EGL_WL_bind_wayland_display "
    }
}

[Glen Whitney]

OK, after looking Philippe Normand's setup and Michael Catanzaro's comments, I am going to try to implement the other recommended standards-compliant definition of the "1px" unit: "the pixel unit refer to the whole number of device pixels that best approximates the reference pixel", where the reference pixel subtends .0213 degrees at the typical viewing distance. I will assume that mobile viewing distance is half that of desktop/laptop viewing distance, and I will assume the latter viewing distances are the same and are equivalent to the "standard" viewing distance at which the reference pixel is 1/96th of an inch. But there are still three unspecified aspects of implementing this standard that I would really appreciate input/guidance on:

1) How to decide what integer multiple "best approximates"? In Philippe's setup, 1.497 pixels would match the reference pixel, and based on his comments, a choice of a multiplier of 1 would match his expectations and apparent Chrome behavior. So I could try straight rounding to the nearest integer, 1.497 is just small enough to round to 1. Or if people think that actually we want a bias toward rounding the multiplier down to match historic behavior in more cases, I could map 0-1.6 to 1 (say), 1.6+ to 2.6 to 2, 2.6+ to 3.6 to 3, etc. Thoughts?

2) How to decide mobile? Michael recommends basing it on screen size, which makes sense. But what width cutoff should I use? 200 mm (a little under 8 inches, to get cellphones in landscape orientation)?

3) Finally, what about tablets? Should there be a size range considered "tablet" between "mobile" and "ordinary screen", and if so, what should be used as the expected viewing distance for a screen in this tablet range?

Thanks for your input; I will be happy to open a new PR for this issue, which should have far less in the way of side effects, once reasonable answers to these three items are settled on.

[Michael Catanzaro]

I suggest researching what other browsers do!

[Glen Whitney]

Ok, from poking around it seems better to use a diagonal cutoff rather than a width. I can't find any recommended specific cutoff so I am going ahead with a 200mm max diagonal to be considered a "handheld" device that would warrant the presumed half-standard expected viewing distance. I have to apologize that I don't have the time/hardware to try and see if there is some intermediate "tablet" setup, so I will go with a two-tier scaling. And to alter the behavior for fewer users, I will round down for values of the "ideal" scaling up to 1.6, 2.6, 3.6 etc., as suggested, and round up otherwise. I will submit a new PR as soon as I can get to it.

Thanks to all for the reports, suggestions, and help.

[Glen Whitney]

Pull request: https://github.com/WebKit/WebKit/pull/28691

[EWS]

Committed 278962@main (5713584438d2): <https://commits.webkit.org/278962@main>

Reviewed commits have been landed. Closing PR #28691 and removing active labels.