W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: [css-images][svg2] gradient rendering and the image-rendering property

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 17 Feb 2016 13:12:13 -0800
Message-ID: <CAAWBYDCVZVL+vBh889GYcwmcsQvHYj62B6koh0YuXR0-pcCj5Q@mail.gmail.com>
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Cc: Simon Fraser <smfr@me.com>, "www-style@w3.org list" <www-style@w3.org>, www-svg <www-svg@w3.org>
On Wed, Feb 17, 2016 at 11:35 AM, Amelia Bellamy-Royds
<amelia.bellamy.royds@gmail.com> wrote:
> But in practice, Chromium at least is making visible
> performance-over-quality tradeoffs, displaying banding in smooth gradients
> and jagged pixelation on sharp transitions (in larger blocks than the actual
> screen resolution).  Banding can also appear in subtle gradients in any
> rendering tool that doesn't do explicit dithering, which can be an issue
> with high-quality printing and SVG.

You appear to be assuming that Blink has a choice in how to render
gradients, and they're purposefully choosing the option that is
fast-but-ugly.  I don't know our details, but I suspect we're actually
in the same boat as Safari, and our underlying graphics library does
not offer any choices in gradient rendering - it just does so, in some
particular way.  As Rik says, we appear to have fixed that to be

This is why we're pushing back against adding a toggle.  There doesn't
appear to *be* an underlying toggle in implementations, so there's
nothing that a CSS-level toggle could *do*.  If gradients are ugly, we
can just fix them.  After we've fixed as best as we can, we can
examine whether a toggle is still desirable.

Received on Wednesday, 17 February 2016 21:13:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC