RESOLVED FIXED 182673
[GTK] whatsapp web blurry in some parts, sharp on others
https://bugs.webkit.org/show_bug.cgi?id=182673
Summary [GTK] whatsapp web blurry in some parts, sharp on others
Fabian Bornschein
Reported 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
Attachments
Patch (1.69 KB, patch)
2018-02-20 01:55 PST, Miguel Gomez
no flags
Patch (2.09 KB, patch)
2018-02-20 02:08 PST, Miguel Gomez
no flags
Adrian Perez
Comment 1 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 ugly.
Carlos Garcia Campos
Comment 2 2018-02-19 22:41:47 PST
Does it also happen with AC disabled?
Miguel Gomez
Comment 3 2018-02-20 01:35:28 PST
(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
Comment 4 2018-02-20 01:55:53 PST
Miguel Gomez
Comment 5 2018-02-20 02:08:57 PST
WebKit Commit Bot
Comment 6 2018-02-20 04:08:47 PST
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 7 2018-02-20 04:46:28 PST
Comment on attachment 334254 [details] Patch Clearing flags on attachment: 334254 Committed r228796: <https://trac.webkit.org/changeset/228796>
WebKit Commit Bot
Comment 8 2018-02-20 04:46:29 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.