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

Issue 778099 link

Starred by 1 user
Status: Fixed
Owner:
michaelludwig@google.com
Closed: Oct 5
Cc:
█ susanjuniab@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

linear-gradient produces inaccurate color transition position

Reported by dntm...@gmail.com, Oct 25 2017 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36

Steps to reproduce the problem:
1. Use CSS linear-gradient to define background with solid color stripes at specific positions
2. Use CSS repeating-linear-gradient with exactly the same background parameters

What is the expected behavior?
linear-gradient and repeating-linear-gradient should render the color transition at the exact specified color stop positions

What went wrong?
linear-gradient and (sometimes) repeating-linear-gradient render color transition not at the specified color stop positions. Instead they try to render some small gradient area *around* the color stop positions even though specific positions are provided.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 62.0.3202.62  Channel: stable
OS Version: OS X 10.12.6
Flash Version:
index.html
4.5 KB View Download

Comment 1 by susanjuniab@chromium.org, Oct 25 2017

Cc: susanjuniab@chromium.org
Labels: -Type-Bug -Pri-2 hasbisect-per-revision Needs-Triage-M62 OS-Windows Pri-1 Type-Bug-Regression
Owner: ericrk@chromium.org
Status: Assigned (was: Unconfirmed)
dntminh@ Thanks for the issue

Able to reproduce this issue on Windows 7, Mac 10.12.6 with Chrome Stable 62.0.3202.62 and Beta 62.0.3202.62. But unable to repro this issue on Canary 64.0.3248.2.
Issue is not seen on Linux Ubuntu 14.04.

Below is the Bisect Information.

Bisect Information:
=====================
Good Build 60.0.3081.0 Revision-467177
Bad Build  60.0.3082.0 Revision-467534

Below is the change log using the per-revision bisect script.

CHANGELOG URL:
===============
https://chromium.googlesource.com/chromium/src/+log/f91ad00d0d78fe00a5d1ca4fc50ace6cd63718a7..4166ab857753a66e9ba6aea475ada0f14b0971d8

From the above change log suspecting below change
https://codereview.chromium.org/2844483003

ericrk@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks.!

Comment 2 by ericwilligers@chromium.org, Oct 25 2017

Labels: Update-Weekly

Comment 3 by ericrk@chromium.org, Oct 25 2017

Labels: -Pri-1 Pri-2
bsalomon@, seems like a gradient rendering issue in Ganesh (SW seems fine). I've confirmed this in the latest Canary, so I think the report of no-repro in 64 was due to  susanjuniab@'s canary being assigned to the SW raster hold-back group.

Can you pass this along to the right person?

Comment 4 by ericrk@chromium.org, Oct 25 2017

Components: -Blink>CSS Internals>GPU>Rasterization
Owner: bsalomon@chromium.org
actually assign to bsalomon@ - see comment #3

Comment 5 Deleted

Comment 6 by mrmi...@gmail.com, Jan 12 2018 

I made a simple JSFiddle to demo the problem of gradient steps not being exactly correct, with more than a pixel of fuzziness and the gradient stop being inaccurate. Please make your browser as wide as possible for maximum effect.

https://jsfiddle.net/mrmills/ng2m1d14/1/

Comment 7 by michaelludwig@google.com, Oct 5

Owner: michaelludwig@google.com
Status: Fixed (was: Assigned)
Both the original html file and jsfiddle exhibit correct behavior with the fix from:

  https://skia.googlesource.com/skia/+/72535fb55a3c7b439530efb48a2b1f55d671530e

commit 72535fb55a3c7b439530efb48a2b1f55d671530e
Author: Michael Ludwig <michaelludwig@google.com>
Date: Thu Oct 04 13:10:29 2018

Reland "Reland "Implement an explicit binary search-based analytic gradient colorizer""
►

Sign in to add a comment