New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 656317 link

Starred by 2 users
Status: WontFix
Owner:
chrishtr@chromium.org
Closed: Nov 2016
Cc:
ajuma@chromium.org
jmukthavaram@chromium.org
█ mbarowsky+blinkimage@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Bad image quality when resized comparing to will-change

Reported by diiiima...@gmail.com, Oct 15 2016 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36

Example URL:

Steps to reproduce the problem:
The quality of resized image with will-change:transform is much better than without.

I attached screenshot of an issue (left side - image with will-change, right - without).

JSFiddle that reproduces the problem – https://jsfiddle.net/DmitrySemenov/uw15g90r/

Firefox & Safari display both images with the same (good) quality.

What is the expected behavior?

What went wrong?
Image quality is off.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 53.0.2785.143  Channel: n/a
OS Version: OS X 10.12.0
Flash Version: Shockwave Flash 23.0 r0
Screen Shot 2016-10-15 at 19.23.00.png
270 KB View Download

Comment 1 by jmukthavaram@chromium.org, Oct 17 2016

Cc: jmukthavaram@chromium.org
Components: Blink>Image
Labels: -Pri-2 -Type-Compat M-56 hasbisect OS-Linux OS-Windows Pri-1 Type-Bug-Regression
Owner: dominicc@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on windows 10, Mac 10.11.4,Linux Ubuntu 14.04 with Chrome stable version-54.0.2840.59.

Manual Bisect:
-------------

Bad Build—-36.0.1950.0- Revision (264960)
Good Build—-36.0.1948.0-Revision (264758)

Bisect Tool Info:
-------------

Change Log:
https://chromium.googlesource.com/chromium/src/+log/d9d942358cb7031681fa8a10924d69e308243e65..f0e87a679aa6d8643079250b90c9865c2b585aa6

Blink CL::
https://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=171874%3A171871

Unable to find the exact suspect from the Blink Roll as it was blank page
hence assigning to  @dominicc from the below Blink Roll
https://chromium.googlesource.com/chromium/src/+/691ce0eff33fe3cd5b19dd6c69f176ccaf9a762c

dominicc @ Please help us to find a right owner if this issue is not related to you.

Comment 2 by dominicc@chromium.org, Oct 21 2016

Cc: ajuma@chromium.org
Owner: ----
Status: Untriaged (was: Assigned)
This is an old regression, it is probably best to have someone triage this.

FYI will-change was enabled in WebKit 171874, d28d53cdef4f40ee4f6f07440f7a01c39dfd2e38.

Comment 3 by schenney@chromium.org, Oct 21 2016

Owner: chrishtr@chromium.org
Status: Assigned (was: Untriaged)
Duplicate? I believe this is expected behavior due to changes in how we decide on the resolution for painting the image when the image destination size is varying.

Comment 4 by chrishtr@chromium.org, Nov 8 2016

Status: WontFix (was: Assigned)
<img> elements which are composited usually have low filter quality for resize.
This is because we have assumptions that compositing is optimizing for speed over
quality. In addition, will-change: transform is an explicit hint to the browser
that the page author wants speed over quality.

If you really need a composited layer for your image, but want higher quality, your
only recourse right now is to use the following hack: put a background color on the
<img>. If it's opaque the background shouldn't show, and our fast path for
composited images will be disabled. However, be aware that that hack might not work
in the future.

This is good feedback however. I'll put an item on our future work list to consider
how to guarantee compositing with high-quality image resizing.
►

Sign in to add a comment