Summary: | [GTK] whatsapp web blurry in some parts, sharp on others | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Fabian Bornschein <plusfabi> | ||||||
Component: | WebKitGTK | Assignee: | Miguel Gomez <magomez> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | aperez, bugs-noreply, cgarcia, cmarcelo, commit-queue, ews-watchlist, kondapallykalyan, luiz, magomez, mcatanzaro, noam, zan | ||||||
Priority: | P2 | ||||||||
Version: | Other | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Linux | ||||||||
See Also: | https://bugzilla.gnome.org/show_bug.cgi?id=793354 | ||||||||
Attachments: |
|
Description
Fabian Bornschein
2018-02-11 02:09:28 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. Does it also happen with AC disabled? (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. Created attachment 334253 [details]
Patch
Created attachment 334254 [details]
Patch
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 Comment on attachment 334254 [details] Patch Clearing flags on attachment: 334254 Committed r228796: <https://trac.webkit.org/changeset/228796> All reviewed patches have been landed. Closing bug. |