Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 76 users
Status: Fixed
Closed: May 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment
WebKit gradients show banding on Chrome
Reported by, Apr 16 2010 Back to list
Chrome Version       :
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: OK
  Firefox 3.x: N/A
         IE 7: N/A
         IE 8: N/A

What steps will reproduce the problem?
1. Open the attached HTML in Chrome. 
2. Note that the gradient is not smooth. 
3. Open the same file in Safari. 
4. Note that the gradient is smooth. 

What is the expected result?
When using a webkit gradient style, the colors should transition cleanly
and gradually without visual banding. 

What happens instead?
In Chrome, the gradient is banded instead of smooth. 

Please provide any additional information below. Attach a screenshot if

260 bytes Download
Labels: -Area-Undefined Area-WebKit
Comment 2 by, Apr 20 2010
Labels: chrome-only Mstone-6
Status: Untriaged
Labels: -Area-WebKit OS-Windows OS-Linux Internals-Skia Area-Internals
Status: Assigned
I am going to guess this is Skia-only. Stephen, can you comment?
Using a color picker, you can see that the RGB values of the gradient are monotonically 
increasing:  16, 17, 18, 19, etc.  The banding is caused by the fact that 8 bits per 
component is just not precise enough to capture the range of human vision, especially 
in the blacks.

We could fix it by doing 16bits per component rendering, which has about 0.1% display 
hardware market penetration right now, or make it look better by dithering, which would 
introduce noise (I imagine the latter is what Safari does).
Comment 5 by, May 6 2010
Can someone upload a screenshot of Safari?  For some reason the original screenshot is 
Here's a screenshot from the Windows build of Safari. (The Mac build of Chrome
renders fine, so that would imply that it is a Skia issue.)
421 KB View Download
Labels: -Mstone-6 Mstone-7
Labels: -Mstone-7 Mstone-X
Comment 10 by, Jan 13 2011
fixed in skia rev. 691

this dithers 32bit linear gradients
Project Member Comment 11 by, Jan 17 2011
The following revision refers to this bug:

r71607 | | Mon Jan 17 14:18:07 PST 2011

Changed paths:

Roll skia r690:r699.

r692 fixes a valgrind error. r691 brings in optional gradient dithering code for 32bit pixels. Disable this in chrome for now.

BUG= 41756 , 69531 , 69452 
To fix this bug, the change to SkUserConfig I landed in r71607 needs to be reverted. This will require rebasing a bunch of tests in webkit. You also need to check how much this affects performance; I'm attaching a simple gradient performance benchmark. I don't know how much of a hit we're willing to take for this, jamesr or mihaip can probably comment on this (for reference, the benchmark gets ~24 fps on my Mac Pro, where we render gradients using CoreGraphics).
2.3 KB View Download
If dithered rendering performance with Skia is comparable to CoreGraphics, then enabling this seems reasonable.
Comment 14 by, Jan 18 2011
Does anyone have a linux or windows box? If so, can you check how many FPS you get in a release build in the attachment to comment 12
a) with a trunk build
b) with a trunk build that doesn't have the SK_DISABLE_DITHER_32BIT_GRADIENT #define in skia/config/SkUserConfig.h ?
Comment 15 by, Apr 20 2011
skia/config/SkUserConfig.h : SK_DISABLE_DITHER_32BIT_GRADIENT
Owner: ----
epoger: Fixing this requires changing a single line (see comment 12 / 15), doing a quick perf sanity check, and then landing many webkit rebaselines. You're probably pretty good at landing baselines at the moment; do you want to give this a try?
Comment 17 Deleted
 Issue 100516  has been merged into this issue.
Comment 19 by, Oct 18 2011
Nico, let me make sure I understand all this:

- There is Skia code that will generate nicer (less "bandy") gradients in , but it is disabled if SK_DISABLE_DITHER_32BIT_GRADIENT is defined.

- SK_DISABLE_DITHER_32BIT_GRADIENT is not defined within the Skia code or build scripts, so Skia-only builds get these nicer gradients already (and no DEPS roll is required to pick up the feature).

- Chrome *does* define SK_DISABLE_DITHER_32BIT_GRADIENT , in , so Chrome is not getting the nicer gradients yet.

There are two concerns associated with removing the definition of SK_DISABLE_DITHER_32BIT_GRADIENT from :

1. there may be a performance hit
2. lots of images will need to be rebaselined for all platforms that use Skia

Have I got all that right?

Yes, that sounds right.
Labels: -Mstone-X -OS-Windows -OS-Linux Mstone-18 OS-All
Hi epoger, do you think you can get to this for m18? shows more banding on mac with skia than it did before, it would be nice if we wouldn't regress this due to the skia switch.
Comment 22 by, Jan 3 2012
SK_DISABLE_DITHER_32BIT_GRADIENT is getting defined (somehow), as verified by debugging chrome. Making this change is trivial -- mod rebaselining images. I will run locally to see how many images are affected.
Comment 23 by, Jan 3 2012
Mike is working on this...
Comment 24 by, Jan 3 2012
Mike- Chrome defines SK_DISABLE_DITHER_32BIT_GRADIENT in
Mike: See comments 11, 12, 19 in this bug :-)
 Issue 108892  has been merged into this issue. (from the dupe) looks really bad: only 11 (!) steps for a gradient from white to black (see screenshot). That's worse than just missing dithering on 8bpp/channel.
Screen shot 2012-01-04 at 9.38.35 PM.png
96.4 KB View Download
Comment 28 by, Jan 5 2012
Yes, multiple color-stops show up a limitation in our current impl. Will fix asap.
Comment 29 by, Jan 5 2012
Two different bugs seem to have gotten conflated here: and are actually displaying different issues with linear gradient.

1. A large smooth gradient across a relatively-narrow section of the color space.
2. A large gradient with a sharp discontinuity in the middle.

I have a pending Skia patch that fixes the latter but not the former (in both cases only for the special case of *purely vertical* linear gradients, since the more general case costs us a 5x performance penalty). It may be able to fix #1 as well; experimenting with that today.

Dithering would not fix #2. As far as we can determine, fixing #2 will require a severe performance hit; we can try to write code to only incur that performance hit if necessary, but there'll be a pretty sharp discontinuity in quality between a gradient that activates the expensive code path and one that doesn't.

A fix for #2 for purely vertical linear gradients (like the example in c#27) is live in Chromium. We don't expect a fix for the general case because of the performance cost of linear interpolation.

I will attempt to turn on dithering immediately following the M18 branch.
Comment 32 Deleted
Comment 33 Deleted
Comment 34 Deleted
Labels: -Mstone-20 bulkmove MovedFrom-20 Mstone-21
If this is still need to be part of M20, punt back.
Labels: -Mstone-21 Mstone-22
Comment 37 by Deleted ...@, Jul 22 2012
I'm trying to use large, subtle radial gradients on a number of sites and this issue is driving me crazy. I'd love to get this fix, which seems to be almost complete already, landed in Chrome before a new site of mine launches (months away, that's why I'm trying to figure this out now).

I'd be happy to try to set up the tests so that they will work with this change, if that would be helpful. I can also try benchmarking, although I don't think dithering should be that big of a deal, performance-wise.

I've attached another test file (with linear and radial gradients) and screenshots in Safari, Firefox Nightly, and Chromium. -moz-linear-gradient and -moz-radial-gradient dither as expected in Firefox.
GradientSafari 5-1-7.png
301 KB View Download
303 KB View Download
436 bytes View Download
GradientChromium 147278.png
90.9 KB View Download
Labels: -Mstone-22 Mstone-23
Owner: ----
Status: Available
I'm moving to a different assignment and don't expect to be able to get to this in the next year. The tools are still not up to supporting a rebaseline of this magnitude, and the Skia team doesn't have any experienced gardeners.
Comment 40 by, Oct 10 2012
Labels: -Mstone-23 MovedFrom-23 Mstone-24
Moving all non essential bugs to the next Milestone
Comment 41 by Deleted ...@, Oct 10 2012
I did some further testing and dithering seems to be disabled in Firefox on Windows and Safari 6. So Chromium is part of the majority in this regard. I think it would be very difficult to get all browsers pointed in the same direction on this issue.
Labels: -Mstone-24
Since the bug has moved few times, removing the milestone label. Please target the right milestone.
Project Member Comment 43 by, Mar 10 2013
Labels: -Internals-Skia -Area-Internals Cr-Internals Cr-Internals-Skia
It's amazing to see this very serious bug preventing the use of any CSS gradients in Chrome. It's been 3 years and 1 month since this was reported to you guys, and since then MS released IE10 which supports smooth CSS gradients, so does Safari, Firefox and even Opera! It's sad to know that Opera will switch to Blink and lose in the same time the ability to render CSS gradients correctly.

Sometime I hope that Google never tried to make a web browser. It's not the amount of features that matter, it's how fast the vendor reacts and its general responsiveness when it come to solving blocking issues like this one in a reasonable time, and 3 years and 1 month IS NOT a reasonable response time.

Palina Zarth
I also wanted to add that according to the W3C guidelines, gradients should be transitionable like any other property, and unfortunately Chrome does not support transitions with gradients at all. 

For information IE10 does support transitioning gradients, and it does it very smoothly, not to say that the gradient itself is very smooth and doesn't have any banding.

For me Chrome is the next IE: a cumbersome software that is too big and too complex in order to be able to resolve bugs like those in less than 3 years delay.
This issue comes up on native Chrome error pages ("The webpage is not available") in the background. 

I thought there was something wrong with my computer or that my eyes were seeing the world at too high a framerate. 
@46 Yes this definitely appears on the Chrome error pages. This is sooo obvious I don't understand how this was tolerated for the past 3+ years!

Just unplug your internet and try accessing any website. 
Chrome cannot render gradients.png
36.6 KB View Download
Comment 48 by, May 24 2013
 Using the test page on #37, I no longer see the banding. I'm on M26 on the mac.
Here is what I see using the test page from #37, I'm on M26 on Windows 7.

Chrome cannot render gradients 2.png
142 KB View Download
Could you merge this issue with this one:

It's the same problem described. Thanks.
Comment 51 Deleted
As reported by #24 from #226753 ( this issue still exists on Chrome 27.
Comment 53 by, May 24 2013
#49 looks much much better than #37, agreed? At least on a Mac monitor, I don't see any banding on #49.
@53 did you forget to display the image at 100% by clicking on it? In Chrome the image will be scaled down (if your screen resolution is lower than the image) making the gradient nice and smooth, however displaying this screenshot at original size is required to see the ugly banding.

If you still don't see them then you really have a problem, either your browser is applying dithering on images to force smooth gradients (, either you're working on a CRT monitor, or last possibility: your eyes are just fucked. Sorry for the expression but it's just so flagrant...

Comment 55 by, May 24 2013
attachment in #37 looks very banded to us
attachment in #49 looks very smooth to us

Several of us in the office are viewing these both on a Mac monitor, and on Linux using an HP monitor.

#54 do you see a quality difference between the attachments in #37 and #49?

Okay that's really crazy, here's a picture of my screen taken with my camera:

3.3 MB View Download
@55 Yes I see a difference, the banding on both #37 and #49 is terrible and is even stronger on #49.

I just uploaded a picture of what I see on Chrome on my laptop. Note that the exact same gradients are super smooth on Firefox, Safari, IE and Opera. Tested all 5 browsers and Chrome is the only one showing the horrible banding, so this is not related to my screen/eyes/whatever.
This bug is affecting the Google logo on Gmail, Google Maps, and so on.

Screenshots attached.
Chrome VS Safari.JPG
95.7 KB View Download
205 KB View Download
206 KB View Download
I just wanted to make sure that the gradient around the Google logo was a CSS gradient and not an image, so inspecting the element shows the following:

#gbx1, #gbx2 {
    background: #f1f1f1;
    background: -webkit-gradient(radial,100 36,0,100 -40,120,from(#fafafa),to(#f1f1f1)),#f1f1f1;

So when you visit Google websites using the Google browser you actually get the worse experience, it is recommend that you access Gmail/Maps/etc. from Safari!

Soon Google will display the following at the bottom of its websites: "Optimized for Firefox, Opera, IE or Safari. Avoid Chrome".

Sorry just one last precision: the previous images are not screenshots but actual pictures of my LCD screen taken with my physical camera.
Comment 61 Deleted
For me, I have not seen this issue in a long time. I go to the links that are provided and 90% of the time, I do not see the issue. The Google logo above is an example
Why is this issue still not merged with 

How can a so serious bug stays unfixed for so many years? With all the information and evidences we have provided to you, at least confirm and provide an ETA!
Do you intend to fix this bug anytime this year? any ETA?
Comment 65 by, Jun 10 2013
I'm sorry, but we have not been able to reproduce what you're seeing. We will keep looking, but at the moment, without a case we can see, we don't know what change to try.
For information this issue is still here in the latest Chrome Canary (Version 29.0.1546.0 canary).

It's been reported for three and a half years, please provide an ETA.
Here's a test case for you that clearly shows banding in Chrome but not in Safari:

9.5 KB View Download
5.0 KB View Download
IE10 also does not have banding. I can reproduce the issue with the jsfiddle of Aug 14, 2013 in Chrome 30.0.1599.37 beta-m. It is a problem for our website that is forcing us to fall back to a background-image. That should not be necessary.

Please also consider adding dithering to gradients besides resolving this issue by removing the overly big color bands.
Comment 69 by, Sep 16 2013
#67 - thanks for the new test-case -- this is a different (internal) issue for our gradients, and we are starting to work on it.

#37 -- I've attached your test case (grad.html). This one is fixed now in chrome, and should be properly dithered.

513 bytes View Download
Here is a very simple test that shows just how horrible gradients look in Chrome. The screenshot is taken with Chrome 30 maximized at 1920x1080. Notice how the body background and large div look horribly banded, but the smaller div with the same gradient background is nice and smooth. All 3 gradients render perfectly smooth in Firefox and IE10.
511 bytes View Download
19.5 KB View Download
Still no fix for this bug after how many years? Seriously? Why is chrome turning into the worst browser?

Here is what I'm seeing and the CSS which causes the banding problem on the current version of chrome on Windows 7.

body {
  background: -webkit-gradient(radial, 50% 50%, 0, 50% 50%, 100, color-stop(0%, #ffffff), color-stop(50%, #ff0000), color-stop(100%, #000000)) fixed;
  background: -webkit-radial-gradient(50% 50%, circle farthest-corner, #ffffff, #ff0000, #000000) fixed;
  background: -moz-radial-gradient(50% 50%, circle farthest-corner, #ffffff, #ff0000, #000000) fixed;
  background: -o-radial-gradient(50% 50%, circle farthest-corner, #ffffff, #ff0000, #000000) fixed;
  background: radial-gradient(50% 50%, circle farthest-corner, #ffffff, #ff0000, #000000) fixed;

The window on the left is Firefox and on the right is Chrome. As we can see, the white center of the chrome gradient is a disk and surrounded by concentric circles (the first circle around the white is the worst). The white circle in the center is totally white (255, 255, 255) out all the way to the visible edge. Test this out for yourselves.

Like a Sun.png
1.2 MB View Download
Comment 73 by, Mar 11 2014
I think the last few are examples of multiple-colors in the gradients running into our 256-entry table.
... why in the world would gradients be limited to 256 colors? And why would 244 of the 256 entries be the *same* color? In my example, there is clearly only 13 total colors used between the red corner and the green area. That means the last 243 entries are just duplicates of the 13th - solid green.
Comment 75 by, Mar 12 2014
sorry, my comment was a bit confusing. It was a note-to-self about a possible implementation reason for the bug, not a public limitation of gradients.
This is a huge issue, its impossible to use rgba gradients for masks in Chrome due to terrible rendering. Fix this!
I agree, this is a pretty important issue, as HTML5/CSS3 are becoming very widespread now, and gradients are surely one of the most important CSS3 features.
I can confirm that the example in my previous post that worked in FF24 still works in FF28. It worked in IE10 and still works in IE11. And of course, it failed in Chrome 30 then and it still fails big time in Chrome 34 now.
Happy Birthday to you, issue ID 41756, you are now 4 years old :) I'm really proud of you 41756, you didn't grow by a bit! 
Sorry I'm late, actually its birthday was yesterday, not today! So it's 4 years and 1 day already. As it's too late to wish you a short and limited life, I can only wish you a long and extended life with many comments and complains! All the best my dear 41756!

Your pal
To :

Maybe we can remove the following flags: 


It's more than 11 versions ahead so those are quite obsolete now, and while it's good to know that you were planning to fix this issue back in version 20, 4 years ago, we're now in version 34, 4 years later, so better be realistic than fantasist especially when so many people are counting on you :)
Another example:

Increase the width of the result container to see color banding.
Banding occurs in the current stable version: 34.0.1847.116 and Canary: 36.0.1946.0 canary

The linear gradient looks great in the latest versions of Firefox & Safari.
There are other cases that are clearly this same horrible gradient bug, but don't result in the same kind of color banding. For example:
In Firefox and IE, this simple repeating gradient makes diagonal black and white lines 2 pixels wide, repeating forever, smoothly drawn and seamlessly repeating.
On Chrome, I don't even know what the heck is happening. It's almost as if the lines aren't even at a 45 degree angle, despite clearly in the CSS that they should be. There is no grey or smoothness between the lines, just this haphazard mixture of random-width white and black chunks, that vary in width even on the same line segment.
112 KB View Download
Comment 84 by, May 31 2014
Here's another site with a whole list of affected samples:

I've also noticed that as you scroll the page the banding flickers between dark bands and light bands.

In my opinion this is a pretty major rendering issue. Any way we could get a progress update on this? 

And just out of curiosity, why would Chrome have this issue but not Firefox even though they both use Skia to draw gradients?
230 KB View Download
Comment 85 by, Jun 25 2014
FYI: Affects SVG gradient rendering as well. Visible banding.
Comment 86 by, Sep 2 2014 also visualises the problem very well.
It looks as if this issue has turned into a catch-all bug for all possible gradient rendering quality issues, even if they have different causes.

It's hard for anyone to look at this bug and make precise sense out of what's going on in it, so I've asked Mike if he could break this down into separate new bugs for each unfixed issue above that has a different cause.  This makes tackling each one more tractable.  (Other Skia folks, please feel free to step in and help here?)

Once that's done, I think this bug should be closed.  The original report in the first comment seems to have been fixed, so all the different legit followon issues people have found would be best tackled separately.
Comment 88 by, Dec 18 2014
Okay I want to make this very clear because I think there's a lot of confusion... None of the examples listed on this thread have been fixed. The original example is still broken (on Canary v41 on Win8.1). #69 the example you posted back saying was fixed is NOT fixed. And every other example I've tried is broken as well. I'm attaching new version's of #1 and #69 that use the standard gradient syntax so you can test this cross-browser.

This has nothing to do with dithering. No browser dithers gradients. Chrome just isn't including all possible color steps in a gradient, and is also creating some sort of banding artifact. IE11 and FF render all of these examples identically. Chrome does not.

I noticed that putting Canary into Ganesh mode through --force-gpu-rasterization fixes ALL of the issues. All gradients look exactly the same as FF and IE in Ganesh mode. So there's clearly a problem when Skia is rendering gradients in software mode.
389 bytes View Download
228 bytes View Download
Comment 89 by, Dec 18 2014
This one still comes out differently than IE and FF even with gpu rasterization though:

Again, IE and FF are like pixel-perfect indentical. Safari looks almost identical as well. It's just Chrome that is rendering significantly differently.
Interesting. Better without Skia for sure, but still full of really weird issues. Check out (changed to 0deg and 500px) and it's still really wrong without Skia. It's like their pixel alignment is off and the repeating is really funny.
Works fine in FF and IE of course, but renders different in the two. In Firefox the first two pixels are solid white, then two black, repeating. IE does a white row, grey, black, grey, repeating. I think it's a difference of aligning the gradient to pixel-center or pixel-edge, which the CSS spec may not really clarify. Either way though, the repeating is smooth and acceptable, unlike in Chrome with or without Skia, which is just wrong no matter what.
Something looks like it changed for the better in Chrome 42, is there a related bug that has details? The jagged edges are no longer present on the gradients at 45 degree angles, but even simple things like the black/white stripes aren't evenly spaced, despite the gradient repeating every 4 pixels...

Comment 92 by Deleted ...@, Sep 26 2015
Just wondering and hoping for an answer: Did this patch introduce temporal dithering? Or is it static? I suffer from eyestrain and noticed some time ago that I cannot use Chrome anymore. Firefox is no problem.
Comment 93 by, Sep 27 2015
Here's the cross-browser CSS for a gradient that makes this issue very apparent using black and white.

    background: linear-gradient(to right, #fff 0%, #000 10%, #000 90%, #fff 100%);

(Attached screenshot is Chrome 45.0.2454.101 (64-bit) on Mac OS X 10.10.5)
Screen Shot 2015-09-27 at 5.08.39 PM.png
384 KB View Download
Labels: Cr-Blink-Paint
Assigning to reed@ for the next step, which is to try implementing a version of
gradients that has larger or unlimited banding resolution. Then we (I? :) ) can
try to figure out the best performance/quality tradeoff point.
Project Member Comment 97 by, Nov 24 2015
The following revision refers to this bug:

commit 32158b3da9a7a21c44698862fc5370c2ed735299
Author: fmalita <>
Date: Tue Nov 24 22:46:42 2015

Enable high-quality linear gradients


Start using Skia's analytical linear gradients (software-only).

The new implementation addresses a couple of fundamental issues present
in the old/LUT-based approach:

  * inexact (or blurred) hard color stops
  * banding artifacts

BUG= 558622 , 41756 , 98436 ,117140,135568, 140208 , 152706 , 177293 , 180783 , 229561 , 233879 , 271552 , 317502 , 375630 , 403959 ,414254, 419344 , 476548 , 486063 ,543625, skia:1077,

Review URL:

Cr-Commit-Position: refs/heads/master@{#361476}


Labels: -chrome-only Chrome-only
Status: Assigned
Florin this bug is done right?
Status: Fixed
Yup, this should be fixed.
I believe this bug has returned in Chrome 59, I'm suddenly seeing gradient banding on all my css linear-gradient definitions right after the update.
21.1 KB View Download
wonder if this is a case where the paint *doesn't* have the dither bit set ...?
Yeah, this does look like it's missing dithering (which is different from the original issue)., do you mind sharing your chrome://gpu output?

Sure, here you go.

Note: there might be some localized system strings in there, notably: Engedélyezve (Enabled), Nincs probléma (no problems found), Nincs lefuttatva (not run), Ismeretlen (unknown).
213 KB View Download

  "Rasterization: Hardware accelerated"

Looks like your system is using GPU rasterization, and we currently disable dithering in that case.  I've opened  issue 731693  for it, if you want to follow.

(the change in 59 is probably that your system was switched from software rasterization to GPU rasterization)
Sign in to add a comment