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

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Wed, 17 Feb 2016 11:53:31 -0800
Message-ID: <CAGN7qDDbte3r+h-MC01WAcMRzjGWPBQrbGztN7WCYp0qFW0-yQ@mail.gmail.com>
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, 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:

> I am quite sympathetic to the argument that we should just make gradient
> rendering good everywhere.
>
> 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.
>

That is a bug that was recently addressed in skia:
https://bugs.chromium.org/p/skia/issues/detail?id=1077
The fix should roll out in a release soon.



> If we create a new `gradient-rendering` property (instead of re-purposing
> `image-rendering`), that solves 2 issues:
>
>    - User agents that can't control gradient rendering can simply
>    indicate that they don't support certain values.  So an `@supports
>    (gradient-rendering: smooth) {}` rule would fail if the renderer always
>    applies some pixel aliasing to gradients, even if they have no problem with
>    smooth image scaling.
>
>    - The keywords can be chosen to make more sense for gradients instead
>    of for image scaling.  The distinction between `crisp-edges` and
>    `pixelated` is perhaps too confusing to factor in ( I had suggested that
>    `crisp-edges` would alias to device pixels only for strict vertical and
>    horizontal gradients, and use smoothing for other angles. )  And perhaps an
>    explicit `dithered` keyword may prove useful for some implementations.
>
> Like the other *-rendering properties, these would be a "hint" from the
> author to the user agent; no one would be deemed non-conforming for failing
> to provide advanced rendering control.
>
> For reference, here are current behaviors, based on a quick test of the
> following two pages on a Windows laptop with a moderately good screen
> resolution:
>
>    - CSS gradients at various angles:
>    https://jsfiddle.net/987q718v/
>    - SVG gradient (center) and CSS gradient:
>
>    http://oreillymedia.github.io/SVG_Colors_Patterns_Gradients/ch07-positioningGradients-files/css-gradient-direction.html
>
> Chrome: visible banding, sharp diagonal transitions aliased to ~2x2 pixel
> blocks
> Edge & Firefox: very subtle banding on the black-to-white gradients,
> diagonal transitions aliased to device pixels.
>
> I couldn't recreate the noticeable blurring on horizontal/vertical
> gradients in Firefox that I've seen designers complain about previously.
> Not sure if that means it's fixed or if certain other features of the
> gradient are required to provoke it.
>
>
Received on Wednesday, 17 February 2016 19:54:01 UTC

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