Bug 182673 – [GTK] whatsapp web blurry in some parts, sharp on others

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

[Fabian Bornschein]

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

[Adrian Perez]

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
ugly.

[Carlos Garcia Campos]

Does it also happen with AC disabled?

[Miguel Gomez]

(In reply to Carlos Garcia Campos from comment #2)
> Does it also happen with AC disabled?

Nope.

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.

[Miguel Gomez]

Created attachment 334253 [details]
Patch

[Miguel Gomez]

Created attachment 334254 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 334254 [details]
Patch

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

[WebKit Commit Bot]

Comment on attachment 334254 [details]
Patch

Clearing flags on attachment: 334254

Committed r228796: <https://trac.webkit.org/changeset/228796>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.