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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Amelia Bellamy-Royds
A discussion at the joint SVG/CSS face-to-face meeting centered on gradient quality, and whether features such as dithering could be supported (or required) to address banding in gradients. 

I brought up that there are already cross-browser inconsistencies in whether colors are anti-aliased when gradients have sharp transitions (color stops at the same offset value to create stripes), and pointed out that anti-aliasing looks better on diagonal stripes but can look fuzzy on horizontal/vertical stripes.  Someone suggested I write up a proposal.  I initially avoided an action, but after discussion moved on I realized that this is essentially the same issue as the image-rendering properties: sometimes you want smooth interpolation, and sometimes you want crisp edges.

So, the basic proposal is as follows: make the image-rendering property apply to gradient images, including CSS and SVG gradients for an element.  Add the proposed "smooth" value to distinguish from "auto", and make the definitions for each value as follows:

auto
The image or gradient should be rendered with an algorithm that balances a smooth appearance with performance.
smooth
The image or gradient should be rendered in such a way that pixilation effects are minimized. In particular, image scaling should smoothly interpolate color transitions, such as by using bilinear interpolation. This is intended for images such as photos.  Gradient rendering should use anti-aliasing on sharp color transitions and may use dithering or similar effects to minimize banding when the color depth of the display cannot create an even color transition.
crisp-edges
The image or gradient should be rendered in a way that preserves contrast and edges in the image.  Images should be scaled with algorithms that do not smooth colors or introduce blur to the image in the process. This is intended for images such as pixel art.  Gradient rendering may (or should?) nonetheless use anti-aliasing to create clean diagonal lines.
pixelated
Images must be scaled with the "nearest neighbor" or similar algorithm, to preserve a "pixelated" look as the image changes in size. Gradients should not use anti-aliasing or dithering.

Some additional complications:
  • For SVG paint servers, should the value in effect on the paint server element be used, or the value in effect on the painted shape?  I think consistency with other *-rendering properties (e.g. for color) is to use the value on the gradient element itself.  Alternatively, the "auto" behavior on a shape could be to use the behavior on the gradient, but a different value on the shape could override it.
  • Should you be able to set different rendering hints on different layers of CSS backgrounds (e.g. to have a smooth gradient overtop of a crisp-edges stripe)?  E.g., with a background-image-rendering property that takes a list of values?  If so, probably also want to introduce equivalent properties for layered SVG fill and stroke paint.

  • For existing SVG content, there may be backwards compatibility issues.  E.g., if image-rendering is set on the <svg> element itself with the expectation that it would only affect <image> elements, but now it also affects gradients.  Not sure if this would break anything badly.
If people are worried about backwards compatibility, an alternative would be to create a distinct `gradient-rendering` property.  If so, I would want `gradient-rendering` to use the same values as `image-rendering` as described above, so authors would only have to memorize one set of keywords.

~Amelia Bellamy-Royds


Reply | Threaded
Open this post in threaded view
|

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

Jelle Mulder-2
Amelia,

Keep up the good work of bringing up these topics.

I would suggest to add a new property not to break old content and have the added benefit of being able to use different properties for different content. Quite often as a designer you'd like to set different behaviours to different objects, i.e. have vectors and bitmaps have different effects. Instead of having to put a pixelation filter, define that and get it to behave the same accross renderers, this might be a great method to have things behave differently. I would even go as far as to suggest playing around with this idea a bit further and allow authors to set methods of dithering. For example to generate a pixelated rendering of gradients that are blocks of pixels (or other units) like 1x1, 2x2, 20x20 and maybe even floats to get specific effects. Hmm,.. how about different rastisations on that to simulate the good old printers (diamonds and stuff). I admit not to be sure how that would work out on the computational side of things, but it certainly would allow for interesting effects to be created. Granted, those are filters really, but could be used as basic filters to great effect on retina display quality levels and be portable to print at the same time. But maybe we should wait for SVG 3.0 to come into view in the next 15 years as things are getting close to recommendation level?

Cheers,

Jelle Mulder



On Wed, 03 Feb 2016 11:11:03 +0800, Amelia Bellamy-Royds <[hidden email]> wrote:

A discussion at the joint SVG/CSS face-to-face meeting centered on gradient quality, and whether features such as dithering could be supported (or required) to address banding in gradients. 

I brought up that there are already cross-browser inconsistencies in whether colors are anti-aliased when gradients have sharp transitions (color stops at the same offset value to create stripes), and pointed out that anti-aliasing looks better on diagonal stripes but can look fuzzy on horizontal/vertical stripes.  Someone suggested I write up a proposal.  I initially avoided an action, but after discussion moved on I realized that this is essentially the same issue as the image-rendering properties: sometimes you want smooth interpolation, and sometimes you want crisp edges.

So, the basic proposal is as follows: make the image-rendering property apply to gradient images, including CSS and SVG gradients for an element.  Add the proposed "smooth" value to distinguish from "auto", and make the definitions for each value as follows:

auto
The image or gradient should be rendered with an algorithm that balances a smooth appearance with performance.
smooth
The image or gradient should be rendered in such a way that pixilation effects are minimized. In particular, image scaling should smoothly interpolate color transitions, such as by using bilinear interpolation. This is intended for images such as photos.  Gradient rendering should use anti-aliasing on sharp color transitions and may use dithering or similar effects to minimize banding when the color depth of the display cannot create an even color transition.
crisp-edges
The image or gradient should be rendered in a way that preserves contrast and edges in the image.  Images should be scaled with algorithms that do not smooth colors or introduce blur to the image in the process. This is intended for images such as pixel art.  Gradient rendering may (or should?) nonetheless use anti-aliasing to create clean diagonal lines.
pixelated
Images must be scaled with the "nearest neighbor" or similar algorithm, to preserve a "pixelated" look as the image changes in size. Gradients should not use anti-aliasing or dithering.

Some additional complications:
  • For SVG paint servers, should the value in effect on the paint server element be used, or the value in effect on the painted shape?  I think consistency with other *-rendering properties (e.g. for color) is to use the value on the gradient element itself.  Alternatively, the "auto" behavior on a shape could be to use the behavior on the gradient, but a different value on the shape could override it.
  • Should you be able to set different rendering hints on different layers of CSS backgrounds (e.g. to have a smooth gradient overtop of a crisp-edges stripe)?  E.g., with a background-image-rendering property that takes a list of values?  If so, probably also want to introduce equivalent properties for layered SVG fill and stroke paint.

  • For existing SVG content, there may be backwards compatibility issues.  E.g., if image-rendering is set on the <svg> element itself with the expectation that it would only affect <image> elements, but now it also affects gradients.  Not sure if this would break anything badly.
If people are worried about backwards compatibility, an alternative would be to create a distinct `gradient-rendering` property.  If so, I would want `gradient-rendering` to use the same values as `image-rendering` as described above, so authors would only have to memorize one set of keywords.

~Amelia Bellamy-Royds





--
Using Opera's mail client: http://www.opera.com/mail/
Reply | Threaded
Open this post in threaded view
|

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

Jonathan Wilkes
In reply to this post by Amelia Bellamy-Royds
What is the difference between "pixelated" and "crisp-edges"?

-Jonathan




On Tuesday, February 2, 2016 10:13 PM, Amelia Bellamy-Royds <[hidden email]> wrote:


A discussion at the joint SVG/CSS face-to-face meeting centered on gradient quality, and whether features such as dithering could be supported (or required) to address banding in gradients. 

I brought up that there are already cross-browser inconsistencies in whether colors are anti-aliased when gradients have sharp transitions (color stops at the same offset value to create stripes), and pointed out that anti-aliasing looks better on diagonal stripes but can look fuzzy on horizontal/vertical stripes.  Someone suggested I write up a proposal.  I initially avoided an action, but after discussion moved on I realized that this is essentially the same issue as the image-rendering properties: sometimes you want smooth interpolation, and sometimes you want crisp edges.

So, the basic proposal is as follows: make the image-rendering property apply to gradient images, including CSS and SVG gradients for an element.  Add the proposed "smooth" value to distinguish from "auto", and make the definitions for each value as follows:

auto
The image or gradient should be rendered with an algorithm that balances a smooth appearance with performance.
smooth
The image or gradient should be rendered in such a way that pixilation effects are minimized. In particular, image scaling should smoothly interpolate color transitions, such as by using bilinear interpolation. This is intended for images such as photos.  Gradient rendering should use anti-aliasing on sharp color transitions and may use dithering or similar effects to minimize banding when the color depth of the display cannot create an even color transition.
crisp-edges
The image or gradient should be rendered in a way that preserves contrast and edges in the image.  Images should be scaled with algorithms that do not smooth colors or introduce blur to the image in the process. This is intended for images such as pixel art.  Gradient rendering may (or should?) nonetheless use anti-aliasing to create clean diagonal lines.
pixelated
Images must be scaled with the "nearest neighbor" or similar algorithm, to preserve a "pixelated" look as the image changes in size. Gradients should not use anti-aliasing or dithering.

Some additional complications:
  • For SVG paint servers, should the value in effect on the paint server element be used, or the value in effect on the painted shape?  I think consistency with other *-rendering properties (e.g. for color) is to use the value on the gradient element itself.  Alternatively, the "auto" behavior on a shape could be to use the behavior on the gradient, but a different value on the shape could override it.
  • Should you be able to set different rendering hints on different layers of CSS backgrounds (e.g. to have a smooth gradient overtop of a crisp-edges stripe)?  E.g., with a background-image-rendering property that takes a list of values?  If so, probably also want to introduce equivalent properties for layered SVG fill and stroke paint.

  • For existing SVG content, there may be backwards compatibility issues.  E.g., if image-rendering is set on the <svg> element itself with the expectation that it would only affect <image> elements, but now it also affects gradients.  Not sure if this would break anything badly.
If people are worried about backwards compatibility, an alternative would be to create a distinct `gradient-rendering` property.  If so, I would want `gradient-rendering` to use the same values as `image-rendering` as described above, so authors would only have to memorize one set of keywords.

~Amelia Bellamy-Royds




Reply | Threaded
Open this post in threaded view
|

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

Rick-2
When I read it, pixelated was nearest neighbour with zero smoothing and crisp edges were anti-aliased.

On Wed, Feb 3, 2016 at 2:15 AM, Jonathan Wilkes <[hidden email]> wrote:
What is the difference between "pixelated" and "crisp-edges"?

-Jonathan




On Tuesday, February 2, 2016 10:13 PM, Amelia Bellamy-Royds <[hidden email]> wrote:


A discussion at the joint SVG/CSS face-to-face meeting centered on gradient quality, and whether features such as dithering could be supported (or required) to address banding in gradients. 

I brought up that there are already cross-browser inconsistencies in whether colors are anti-aliased when gradients have sharp transitions (color stops at the same offset value to create stripes), and pointed out that anti-aliasing looks better on diagonal stripes but can look fuzzy on horizontal/vertical stripes.  Someone suggested I write up a proposal.  I initially avoided an action, but after discussion moved on I realized that this is essentially the same issue as the image-rendering properties: sometimes you want smooth interpolation, and sometimes you want crisp edges.

So, the basic proposal is as follows: make the image-rendering property apply to gradient images, including CSS and SVG gradients for an element.  Add the proposed "smooth" value to distinguish from "auto", and make the definitions for each value as follows:

auto
The image or gradient should be rendered with an algorithm that balances a smooth appearance with performance.
smooth
The image or gradient should be rendered in such a way that pixilation effects are minimized. In particular, image scaling should smoothly interpolate color transitions, such as by using bilinear interpolation. This is intended for images such as photos.  Gradient rendering should use anti-aliasing on sharp color transitions and may use dithering or similar effects to minimize banding when the color depth of the display cannot create an even color transition.
crisp-edges
The image or gradient should be rendered in a way that preserves contrast and edges in the image.  Images should be scaled with algorithms that do not smooth colors or introduce blur to the image in the process. This is intended for images such as pixel art.  Gradient rendering may (or should?) nonetheless use anti-aliasing to create clean diagonal lines.
pixelated
Images must be scaled with the "nearest neighbor" or similar algorithm, to preserve a "pixelated" look as the image changes in size. Gradients should not use anti-aliasing or dithering.

Some additional complications:
  • For SVG paint servers, should the value in effect on the paint server element be used, or the value in effect on the painted shape?  I think consistency with other *-rendering properties (e.g. for color) is to use the value on the gradient element itself.  Alternatively, the "auto" behavior on a shape could be to use the behavior on the gradient, but a different value on the shape could override it.
  • Should you be able to set different rendering hints on different layers of CSS backgrounds (e.g. to have a smooth gradient overtop of a crisp-edges stripe)?  E.g., with a background-image-rendering property that takes a list of values?  If so, probably also want to introduce equivalent properties for layered SVG fill and stroke paint.

  • For existing SVG content, there may be backwards compatibility issues.  E.g., if image-rendering is set on the <svg> element itself with the expectation that it would only affect <image> elements, but now it also affects gradients.  Not sure if this would break anything badly.
If people are worried about backwards compatibility, an alternative would be to create a distinct `gradient-rendering` property.  If so, I would want `gradient-rendering` to use the same values as `image-rendering` as described above, so authors would only have to memorize one set of keywords.

~Amelia Bellamy-Royds







--
Soap and education are not as sudden as a massacre, but they are more
deadly in the long run.
        -- Mark Twain



Reply | Threaded
Open this post in threaded view
|

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

Jonathan Wilkes
Two more questions:

For "crisp-edges": are edges sharp only on axis-aligned lines, or is there a fudge-factor to sharpen lines that are "nearly" straight?  I'd imagine with
affine transforms it must be the latter, but then how does the implementor make the call?  A large enough inconsistency among browsers would make
it difficult for frameworks to effectively leverage this value.

For both values: What about consistency of line-thickness?  Chromium does some very creative interpretation of "shape-rendering: crispEdges"
when you scale a rectangle with a 1px stroke, for example.  But I wouldn't call it buggy because the spec itself is vague.

-Jonathan




On Wednesday, February 3, 2016 10:52 AM, Rick <[hidden email]> wrote:


When I read it, pixelated was nearest neighbour with zero smoothing and crisp edges were anti-aliased.

On Wed, Feb 3, 2016 at 2:15 AM, Jonathan Wilkes <[hidden email]> wrote:
What is the difference between "pixelated" and "crisp-edges"?

-Jonathan




On Tuesday, February 2, 2016 10:13 PM, Amelia Bellamy-Royds <[hidden email]> wrote:


A discussion at the joint SVG/CSS face-to-face meeting centered on gradient quality, and whether features such as dithering could be supported (or required) to address banding in gradients. 

I brought up that there are already cross-browser inconsistencies in whether colors are anti-aliased when gradients have sharp transitions (color stops at the same offset value to create stripes), and pointed out that anti-aliasing looks better on diagonal stripes but can look fuzzy on horizontal/vertical stripes.  Someone suggested I write up a proposal.  I initially avoided an action, but after discussion moved on I realized that this is essentially the same issue as the image-rendering properties: sometimes you want smooth interpolation, and sometimes you want crisp edges.

So, the basic proposal is as follows: make the image-rendering property apply to gradient images, including CSS and SVG gradients for an element.  Add the proposed "smooth" value to distinguish from "auto", and make the definitions for each value as follows:

auto
The image or gradient should be rendered with an algorithm that balances a smooth appearance with performance.
smooth
The image or gradient should be rendered in such a way that pixilation effects are minimized. In particular, image scaling should smoothly interpolate color transitions, such as by using bilinear interpolation. This is intended for images such as photos.  Gradient rendering should use anti-aliasing on sharp color transitions and may use dithering or similar effects to minimize banding when the color depth of the display cannot create an even color transition.
crisp-edges
The image or gradient should be rendered in a way that preserves contrast and edges in the image.  Images should be scaled with algorithms that do not smooth colors or introduce blur to the image in the process. This is intended for images such as pixel art.  Gradient rendering may (or should?) nonetheless use anti-aliasing to create clean diagonal lines.
pixelated
Images must be scaled with the "nearest neighbor" or similar algorithm, to preserve a "pixelated" look as the image changes in size. Gradients should not use anti-aliasing or dithering.

Some additional complications:
  • For SVG paint servers, should the value in effect on the paint server element be used, or the value in effect on the painted shape?  I think consistency with other *-rendering properties (e.g. for color) is to use the value on the gradient element itself.  Alternatively, the "auto" behavior on a shape could be to use the behavior on the gradient, but a different value on the shape could override it.
  • Should you be able to set different rendering hints on different layers of CSS backgrounds (e.g. to have a smooth gradient overtop of a crisp-edges stripe)?  E.g., with a background-image-rendering property that takes a list of values?  If so, probably also want to introduce equivalent properties for layered SVG fill and stroke paint.

  • For existing SVG content, there may be backwards compatibility issues.  E.g., if image-rendering is set on the <svg> element itself with the expectation that it would only affect <image> elements, but now it also affects gradients.  Not sure if this would break anything badly.
If people are worried about backwards compatibility, an alternative would be to create a distinct `gradient-rendering` property.  If so, I would want `gradient-rendering` to use the same values as `image-rendering` as described above, so authors would only have to memorize one set of keywords.

~Amelia Bellamy-Royds







--
Soap and education are not as sudden as a massacre, but they are more
deadly in the long run.
        -- Mark Twain





Reply | Threaded
Open this post in threaded view
|

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

Simon Fraser-4
In reply to this post by Amelia Bellamy-Royds
On Feb 2, 2016, at 7:11 pm, Amelia Bellamy-Royds <[hidden email]> wrote:

A discussion at the joint SVG/CSS face-to-face meeting centered on gradient quality, and whether features such as dithering could be supported (or required) to address banding in gradients. 

I brought up that there are already cross-browser inconsistencies in whether colors are anti-aliased when gradients have sharp transitions (color stops at the same offset value to create stripes), and pointed out that anti-aliasing looks better on diagonal stripes but can look fuzzy on horizontal/vertical stripes.  Someone suggested I write up a proposal.  I initially avoided an action, but after discussion moved on I realized that this is essentially the same issue as the image-rendering properties: sometimes you want smooth interpolation, and sometimes you want crisp edges.

So, the basic proposal is as follows: make the image-rendering property apply to gradient images, including CSS and SVG gradients for an element.  Add the proposed "smooth" value to distinguish from "auto", and make the definitions for each value as follows:

auto
The image or gradient should be rendered with an algorithm that balances a smooth appearance with performance.
smooth
The image or gradient should be rendered in such a way that pixilation effects are minimized. In particular, image scaling should smoothly interpolate color transitions, such as by using bilinear interpolation. This is intended for images such as photos.  Gradient rendering should use anti-aliasing on sharp color transitions and may use dithering or similar effects to minimize banding when the color depth of the display cannot create an even color transition.
crisp-edges
The image or gradient should be rendered in a way that preserves contrast and edges in the image.  Images should be scaled with algorithms that do not smooth colors or introduce blur to the image in the process. This is intended for images such as pixel art.  Gradient rendering may (or should?) nonetheless use anti-aliasing to create clean diagonal lines.
pixelated
Images must be scaled with the "nearest neighbor" or similar algorithm, to preserve a "pixelated" look as the image changes in size. Gradients should not use anti-aliasing or dithering.

Some additional complications:
  • For SVG paint servers, should the value in effect on the paint server element be used, or the value in effect on the painted shape?  I think consistency with other *-rendering properties (e.g. for color) is to use the value on the gradient element itself.  Alternatively, the "auto" behavior on a shape could be to use the behavior on the gradient, but a different value on the shape could override it.
  • Should you be able to set different rendering hints on different layers of CSS backgrounds (e.g. to have a smooth gradient overtop of a crisp-edges stripe)?  E.g., with a background-image-rendering property that takes a list of values?  If so, probably also want to introduce equivalent properties for layered SVG fill and stroke paint.

  • For existing SVG content, there may be backwards compatibility issues.  E.g., if image-rendering is set on the <svg> element itself with the expectation that it would only affect <image> elements, but now it also affects gradients.  Not sure if this would break anything badly.
If people are worried about backwards compatibility, an alternative would be to create a distinct `gradient-rendering` property.  If so, I would want `gradient-rendering` to use the same values as `image-rendering` as described above, so authors would only have to memorize one set of keywords.

This is an interesting proposal, and goes nicely hand-in-hand with image-rendering as applied to images.

However, in WebKit, gradient rendering is supplied by the underlying graphics framework (CoreGraphics), and we don’t have the knobs to tune to control how gradient rendering behaves. My preference would be that gradient rendering just looks good everywhere.

If we did have a “high quality” option that is more expensive (perhaps it does dithering), then I can see a “smooth” value being useful, but I think the spec is going to have to allow UAs to continue to do what they do now.

Simon

Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Wed, Feb 17, 2016 at 9:43 AM, Simon Fraser <[hidden email]> wrote:
> However, in WebKit, gradient rendering is supplied by the underlying
> graphics framework (CoreGraphics), and we don’t have the knobs to tune to
> control how gradient rendering behaves. My preference would be that gradient
> rendering just looks good everywhere.

Agreed.

> If we did have a “high quality” option that is more expensive (perhaps it
> does dithering), then I can see a “smooth” value being useful, but I think
> the spec is going to have to allow UAs to continue to do what they do now.

I'm also fine with image-rendering being used in this way.  It's
currently specified to only apply to *scaling* of images, but it's a
minor wording tweak to also allow it to apply to *generated* images.

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Amelia Bellamy-Royds
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.

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:
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.

Reply | Threaded
Open this post in threaded view
|

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

Rik Cabanier-2


On Wed, Feb 17, 2016 at 11:35 AM, Amelia Bellamy-Royds <[hidden email]> 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:
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.


Reply | Threaded
Open this post in threaded view
|

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

Simon Fraser-4
In reply to this post by Amelia Bellamy-Royds
On Feb 17, 2016, at 11:35 AM, Amelia Bellamy-Royds <[hidden email]> 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.

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.
I don’t think that’s an appropriate use of @supports(). We don’t spec CSS properties whose implementation is optional based on whether the UA can implement something; we spec them so that everyone can implement them, and allow UA differences via ‘auto’ values.

  • 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:
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.


Given that Rick has said that this is a Chrome bug that has been fixed, do you still think this new property is required?

Simon

Reply | Threaded
Open this post in threaded view
|

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

Amelia Bellamy-Royds

Given that Rick has said that this is a Chrome bug that has been fixed, do you still think this new property is required?


I'm ambivalent. If implementers want to focus on improving gradient rendering everywhere instead of adding multiple rendering options, and believe that it can be done without performance trade-offs, that sounds good to me.  Particular rendering options like dithering could be left up to the implementation, with graphics software for print being more likely to benefit from them.  

~ABR
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
In reply to this post by Amelia Bellamy-Royds
On Wed, Feb 17, 2016 at 11:35 AM, Amelia Bellamy-Royds
<[hidden email]> 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
prettier.

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.

~TJ