Bug 131347 – [GTK] Several hidpi tests are failing

• Component: WebKitGTK
• Status: UNCONFIRMED

[Martin Robinson]

We need support for getting the scaling factor from the system.

[Owen Taylor]

The status of this is that I patches that I think are fine (http://fishsoup.net/misc/webkit-hidpi-patches), but testing them in the test framework: 

 - Requires rebasing the reference build to a newer version of GTK+/cairo/etc - which creates some amount of new failures in the test suite
 - Would require rebasing the reference build to a Git snapshot of cairo

I've been spending some effort trying to get a cairo release released.

[Atri Bhattacharya]

Hi!
Is there a released version of webkitgtk that carries the hidpi patches? I have version 2.4.6 built against the recent cairo (1.14.0) but I still see very fuzzy text on hidpi displays.

Thanks.

[Michael Kuhn]

Created attachment 243575 [details]
Add HighDPI support.

Because HighDPI support is only available in WebKitGTK 2.6 and quite a few applications (Evolution, Empathy, …) still depend on 2.4, I have backported the patches from 2.6 and adapted some of the patches found at the previously posted link for 2.4.

The attached patch applies to 2.4.7 and seems to work based on local tests.

[Michael Catanzaro]

My understanding is that this feature is complete in 2.6.0, and no further patches are needed. That sound right, Owen? (Thanks for your help!)

Regarding backporting to 2.4: I'm indifferent. There is one big advantage to not backporting new features: it's incentive for apps to upgrade to modern WebKit.

[Carlos Garcia Campos]

(In reply to comment #3)
> Created attachment 243575 [details]
> Add HighDPI support.
> 
> Because HighDPI support is only available in WebKitGTK 2.6 and quite a few
> applications (Evolution, Empathy, …) still depend on 2.4, I have backported
> the patches from 2.6 and adapted some of the patches found at the previously
> posted link for 2.4.
> 
> The attached patch applies to 2.4.7 and seems to work based on local tests.

Merged in 2.4 http://trac.webkit.org/changeset/184466

[Carlos Alberto Lopez Perez]

The following two tests have started working with the upgrade of GTK+, Cairo, Gdk-Pixbuf and GLib done in r186500 <http://trac.webkit.org/r186500>.

fast/hidpi/image-srcset-change-dynamically-from-js-2x.html
fast/hidpi/image-srcset-fraction-1.5x.html
fast/hidpi/image-srcset-fraction.html
fast/hidpi/image-srcset-invalid-inputs-except-one.html
fast/hidpi/image-srcset-simple-2x.html
fast/hidpi/image-srcset-src-selection-2x.html

And this new others have started to fail:

fast/backgrounds/hidpi-background-image-contain-cover-scale-needs-more-precision.html
fast/hidpi/filters-blur.html
fast/hidpi/filters-hue-rotate.html
fast/hidpi/filters-invert.html
fast/hidpi/filters-multiple.html
fast/hidpi/filters-reference.html


I have updated the expectations file on http://trac.webkit.org/changeset/186513

[Michael Catanzaro]

The following failing tests were marked against this bug despite not being mentioned here. Reopening until these are fixed:

webkit.org/b/131347 fast/backgrounds/hidpi-bitmap-background-repeat-on-subpixel-position.html [ ImageOnlyFailure ]
webkit.org/b/131347 fast/backgrounds/hidpi-generated-gradient-background-on-subpixel-position.html [ ImageOnlyFailure Pass ]
webkit.org/b/131347 fast/borders/hidpi-border-image-gradient-on-subpixels.html [ ImageOnlyFailure ]
webkit.org/b/131347 fast/borders/hidpi-border-radius-with-subpixel-margin-not-renderable.html [ ImageOnlyFailure ]
webkit.org/b/131347 fast/borders/hidpi-double-border-with-border-radius-always-produce-solid-line.html [ ImageOnlyFailure ]
webkit.org/b/131347 fast/borders/hidpi-simple-hairline-border-painting.html [ ImageOnlyFailure ]
webkit.org/b/131347 fast/hidpi/clip-text-in-hidpi.html [ Failure Pass Missing ]
webkit.org/b/131347 fast/hidpi/image-set-background-dynamic.html [ Failure Pass Missing ]
webkit.org/b/131347 fast/hidpi/image-set-border-image-dynamic.html [ Failure Pass Missing ]
webkit.org/b/131347 fast/hidpi/image-srcset-png-canvas.html [ ImageOnlyFailure Pass ]
webkit.org/b/131347 fast/hidpi/filters-morphology.html [ ImageOnlyFailure Pass ]
webkit.org/b/131347 fast/inline-block/hidpi-margin-top-with-subpixel-value-and-overflow-hidden.html [ ImageOnlyFailure ]
webkit.org/b/131347 fast/inline/hidpi-inline-selection-leaves-gap.html [ ImageOnlyFailure ]
webkit.org/b/131347 fast/inline/hidpi-inline-text-decoration-with-subpixel-value.html [ ImageOnlyFailure ]
webkit.org/b/131347 fast/inline/hidpi-pixel-gap-between-adjacent-selection-inlines.html [ ImageOnlyFailure ]
webkit.org/b/131347 fast/inline/hidpi-select-inline-on-subpixel-position.html [ ImageOnlyFailure ]
webkit.org/b/131347 fast/layers/hidpi-box-positioned-off-by-one-when-transform-is-present.html [ ImageOnlyFailure ]
webkit.org/b/131347 fast/layers/hidpi-transform-on-child-content-is-mispositioned.html [ Crash ImageOnlyFailure Pass ]
webkit.org/b/131347 fast/repaint/hidpi-absolute-positioned-element-wrong-cliprect-after-move.html [ Failure ]
webkit.org/b/131347 fast/repaint/hidpi-content-inside-iframe-leaves-trails.html [ Failure ]
webkit.org/b/131347 fast/repaint/hidpi-device-pixel-based-repaint-rect-tracking.html [ Failure ]
webkit.org/b/131347 fast/repaint/hidpi-transform-on-subpixel-repaintrect.html [ Failure ]
webkit.org/b/131347 fast/repaint/hidpi-wrong-repaint-rect-when-parent-has-noncompositing-transform.html [ Failure ]
webkit.org/b/131347 svg/custom/hidpi-masking-clipping.svg [ Failure ImageOnlyFailure Timeout ]
webkit.org/b/131347 svg/text/hidpi-text-selection-rect-position.html [ ImageOnlyFailure ]

[Michael Catanzaro]

Note that the tests Carlos Lopez mentioned in comment #6 have a separate bug, bug #146731.

[Michael Catanzaro]

(In reply to comment #7)
> fast/borders/hidpi-border-image-gradient-on-subpixels.html [
> ImageOnlyFailure ]

This one is fixed since r199034. Updated expectations in r199270.

[Carlos Alberto Lopez Perez]

More hidpi tests failing:

http/tests/loading/hidpi-preload-picture-sizes.html fails since it was added on r194865. It is only test of 4 that were added on that rev that fails.

fast/hidpi/filters-morphology.html now crashes also.

fast/table/hidpi-collapsed-border-with-odd-pixel-width.html fails since it was added on r197524

And so on...

I have updated the list of hidpi tests currently failing on: http://trac.webkit.org/changeset/200472/trunk/LayoutTests/platform/gtk/TestExpectations

Question (for those with a hidpi screen)... Do we even support hidpi?

If we support it.. maybe this tests are failing because of the GTK+ version that we use on the JHBuild or something like that?

[Michael Catanzaro]

(In reply to comment #10)
> Do we even support hidpi?

Yes, our hidpi support is reportedly very good relative to our competitors. Firefox requires manually tweaking some hidden about:config setting so it's broken for all but expert users, for example.
 
> If we support it.. maybe this tests are failing because of the GTK+ version
> that we use on the JHBuild or something like that?

No way, our GTK+ is plenty new enough.

[Martin Robinson]

(In reply to comment #11)
> (In reply to comment #10)
> > Do we even support hidpi?
> 
> Yes, our hidpi support is reportedly very good relative to our competitors.
> Firefox requires manually tweaking some hidden about:config setting so it's
> broken for all but expert users, for example.

Weird. I have a hidpi laptop and scaling seems to be working fine in Firefox, but perhaps it is broken in some more subtle way.

[Debarshi Ray]

I have been using HiDpi for the last 2 years.

(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > Do we even support hidpi?
> > 
> > Yes, our hidpi support is reportedly very good relative to our competitors.

Yes, the Epiphany / WebKitGTK+ combo definitely supports HiDpi. It has been that way ever since I first tried them on such hardware.

> > Firefox requires manually tweaking some hidden about:config setting so it's
> > broken for all but expert users, for example.
> 
> Weird. I have a hidpi laptop and scaling seems to be working fine in
> Firefox, but perhaps it is broken in some more subtle way.

Things have recently improved in Firefox. Recent versions of Fedora build Firefox with GTK+ 3.x and those have HiDpi support out of the box.

However, this wasn't always the case. Back when I first started using HiDpi things would show up really tiny in both Firefox and Chrome. As Michael says, the former had some about:config setting that could be tweaked to address this, but I am not aware of any such knob in Chrome.

[Carlos Garcia Campos]

*** Bug 168228 has been marked as a duplicate of this bug. ***

[Glen Whitney]

Created attachment 463540 [details]
webkitgtk.org in MiniBrowser on 283dpi screen

[Glen Whitney]

Created attachment 463541 [details]
webkitgtk.org in Firefox on 283 dpi screen

[Glen Whitney]

Created attachment 463542 [details]
webkitgtk.org in MiniBrowser with GDK_SCALE=3 on 283 dpi screen

[Glen Whitney]

Five years on, what's the status of this issue? I ask because on my 283 dpi laptop runnning OpenSUSE Tumbleweed with their latest build of xfce 4.17, out of the box the 2.38.2 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).

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 I just attached. It would be desirable for WebkitGTK to simultaneously get px measurements correct and fonts the appropriate sizes.)

Thanks for any status/guidance on this you can offer. In particular, these problems make html email more or less unreadable in Evolution, which would otherwise be my mail reader of choice.

[Glen Whitney]

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 above 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]

[Michael Catanzaro]

I would report a new bug for this. It's going to go unnoticed here in a layout test failure bug. I was not aware of general problems with hidpi support....