We need support for getting the scaling factor from the system.
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.
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.
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.
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.
(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
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>.
And this new others have started to fail:
I have updated the expectations file on http://trac.webkit.org/changeset/186513
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 ]
Note that the tests Carlos Lopez mentioned in comment #6 have a separate bug, bug #146731.
(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.
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?
(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.
(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.
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.
*** Bug 168228 has been marked as a duplicate of this bug. ***