Bug 182673 - [GTK] whatsapp web blurry in some parts, sharp on others
Summary: [GTK] whatsapp web blurry in some parts, sharp on others
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: Unspecified Linux
: P2 Normal
Assignee: Miguel Gomez
Depends on:
Reported: 2018-02-11 02:09 PST by Fabian Bornschein
Modified: 2018-02-20 04:46 PST (History)
12 users (show)

See Also:

Patch (1.69 KB, patch)
2018-02-20 01:55 PST, Miguel Gomez
no flags Details | Formatted Diff | Diff
Patch (2.09 KB, patch)
2018-02-20 02:08 PST, Miguel Gomez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Bornschein 2018-02-11 02:09:28 PST
https://bugzilla.gnome.org/show_bug.cgi?id=793354 <- (BGO)

Webkit-GTK version: 2.18.6

If you use whatsapp web on a HiDPI display, some parts are rendered sharp, others look blurry to very blurry. It's completely random.

There is an example screenshot in the original bugreport on BGO
Comment 1 Adrian Perez 2018-02-19 10:44:47 PST
I can confirm that this also happens to me. Of course with a  HiDPI
display and a 2x scaling factor, running on an Intel HD Graphics 520
GPU (Skylake), with the Open Source driver (Mesa 17.3.4).

Similar blurry artifacts happen in other websites like Google Inbox
(https://inbox.google.com). I cannot remember any others from the top
of my head, but I am sure of having seen this in a few others — I'll
try to remember to comment here if I find another website which does
not need creating an account for reproducing.

The websites which exhibit this issue are still usable (e.g. text can
be read okay, input works properly), but the blurriness looks quite
Comment 2 Carlos Garcia Campos 2018-02-19 22:41:47 PST
Does it also happen with AC disabled?
Comment 3 Miguel Gomez 2018-02-20 01:35:28 PST
(In reply to Carlos Garcia Campos from comment #2)
> Does it also happen with AC disabled?


It's a problem with the size of the backingStore created by CoordinatedGraphicsLayer, which is not following the required scale factors.

CoordinatedGraphicsLayer::createBackingStore() uses effectiveContentsScale() to get the scale factor to apply. But effectiveContentsScale() returns always 1 if selfOrAncestorHaveNonAffineTransforms() returns true.

The weird part is that selfOrAncestorHaveNonAffineTransforms() returns true if the layer has an ongoing animation, which effectively means that animated layers won't use the appropriate backingStore size.

I don't see why that is intended. I've looked into that code history and there is a comment about "disabling progressive tiling for animated layers" years ago but I don't see the reason to do it. Maybe at hat point they wanted to perform the scaling during the composition stage to save memory. But the problem with that is that it causes blurry rendering, as we can see in this bug.

IMO we should be using the scale factor even if the layer is animated.
Comment 4 Miguel Gomez 2018-02-20 01:55:53 PST
Created attachment 334253 [details]
Comment 5 Miguel Gomez 2018-02-20 02:08:57 PST
Created attachment 334254 [details]
Comment 6 WebKit Commit Bot 2018-02-20 04:08:47 PST
Comment on attachment 334254 [details]

Rejecting attachment 334254 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', 334254, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
rdparty/autoinstalled/mechanize/_urllib2_fork.py", line 332, in _call_chain
    result = func(*args)
  File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_urllib2_fork.py", line 1170, in https_open
    return self.do_open(conn_factory, req)
  File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_urllib2_fork.py", line 1118, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error [Errno 60] Operation timed out>

Full output: http://webkit-queues.webkit.org/results/6588792
Comment 7 WebKit Commit Bot 2018-02-20 04:46:28 PST
Comment on attachment 334254 [details]

Clearing flags on attachment: 334254

Committed r228796: <https://trac.webkit.org/changeset/228796>
Comment 8 WebKit Commit Bot 2018-02-20 04:46:29 PST
All reviewed patches have been landed.  Closing bug.