Bug 150940 – Gradient color interpolation incorrect for colors with alpha (need to interpolate premultiplied colors)

• Component: CSS
• Status: RESOLVED FIXED

Currently the following gradients produce different results despite they should render the same:
 - opaque black to transparent black
 - opaque black to transparent white
 - opaque black to transparent anything

All transparent anythings are in fact the same color, a clear color, no matter what the underlying RGB components say. It seems all four components are currently linearly interpolated, resulting in a very odd gradient -- the second one has a semitransparent gray in the middle. For semitransparent endpoint colors we have the same issue: their RBG components affect the interpolated colors too much, in an unnatural way.

No matter in which color space colors are interpolated, their components should be weighted according to their alpha component.

Firefox seems to use the following weighted approach, producing a much more visually appealing gradient:

float r3 = (r1 * a1 * (1.0 - fraction) + r2 * a2 * fraction) / ((1.0 - fraction) * a1 + fraction * a2);
float g3 = (g1 * a1 * (1.0 - fraction) + g2 * a2 * fraction) / ((1.0 - fraction) * a1 + fraction * a2);
float b3 = (b1 * a1 * (1.0 - fraction) + b2 * a2 * fraction) / ((1.0 - fraction) * a1 + fraction * a2);
float a3 = a1 * (1.0 - fraction) + a2 * fraction;

[Simon Fraser (smfr)]

This is because we don't interpolate gradients in non-premultiplied colors, because CG can't do this yet.

What do you mean by 'CG can't do this yet'?
It is obviously possible...

(In reply to comment #1)
> This is because we don't interpolate gradients in non-premultiplied colors,
> because CG can't do this yet.

[Darin Adler]

The OS X and iOS graphics framework, Core Graphics, that WebKit uses to draw on those operating systems has a gradient feature that does not have a mode where it properly handles this. If we wanted to fix this problem in WebKit without waiting for the Core Graphics we would have to write a new gradient implementation that bypasses the Core Graphics Framework. Our plan is to instead ask Apple to add this feature to the Core Graphics framework.

(In reply to comment #3)
> The OS X and iOS graphics framework, Core Graphics, that WebKit uses to draw
> on those operating systems has a gradient feature that does not have a mode
> where it properly handles this. If we wanted to fix this problem in WebKit
> without waiting for the Core Graphics we would have to write a new gradient
> implementation that bypasses the Core Graphics Framework. Our plan is to
> instead ask Apple to add this feature to the Core Graphics framework.

Ah, I see. So is this a known/confirmed issue? One may argue for both approaches of drawing such a gradient.

How does the collaboration with Apple work in such scenarios? Who even decides who's right and who's wrong? Is there a specification on how these gradients should be drawn?

[Darin Adler]

(In reply to comment #4)
> So is this a known/confirmed issue?

Yes. Simon personally contacted the team at Apple responsible for Core Graphics, a while back, to let them know about this issue.

[Simon Fraser (smfr)]

(In reply to comment #4)
> How does the collaboration with Apple work in such scenarios? Who even
> decides who's right and who's wrong? Is there a specification on how these
> gradients should be drawn?

This is specified by CSS: <https://drafts.csswg.org/css-images/#gradients>

"with the interpolation taking place in premultiplied RGBA space"

but that text is expected to change once Mac and iOS can support interpolation in non-premultiplied.

> "with the interpolation taking place in premultiplied RGBA space"

> but that text is expected to change once Mac and iOS can support
> interpolation in non-premultiplied.

Mh, I'm a little confused now as I'm not quite familiar with this terminology. Is interpolation in premultiplied RGBA what we are seeing now or what would be the correct thing to do? Why would that text change once Core Graphics decides to ship a fix for this bug?

[Simon Fraser (smfr)]

(In reply to comment #7)
> > "with the interpolation taking place in premultiplied RGBA space"
> 
> > but that text is expected to change once Mac and iOS can support
> > interpolation in non-premultiplied.
> 
> Mh, I'm a little confused now as I'm not quite familiar with this
> terminology. Is interpolation in premultiplied RGBA what we are seeing now
> or what would be the correct thing to do?

That's what you're seeing now. Transparent red in premultiplied color just becomes transparent, so any time you interpolate from it you end up with grayish intermediate values.

> Why would that text change once Core Graphics decides to ship a fix for this bug?

Because all browsers would then be able to interpolate in non-premultiplied color, and the CSS working group would change the text (at least for the next level of the spec).

> > Mh, I'm a little confused now as I'm not quite familiar with this
> > terminology. Is interpolation in premultiplied RGBA what we are seeing now
> > or what would be the correct thing to do?
> 
> That's what you're seeing now. Transparent red in premultiplied color just
> becomes transparent, so any time you interpolate from it you end up with
> grayish intermediate values.

Sorry if this is really obvious and I am missing something, but that makes only little sense to me.

I am currently seeing this behavior in Safari:
[opaque black (0,0,0,1)] => [semitransparent dark red (128,0,0,0.5)] => [transparent red (255,0,0,0)] (all components interpolated linearly)

However, I think it should look like this: (and it does in Firefox)
[opaque black (0,0,0,1)] => [semitransparent black (0,0,0,0.5)] => [transparent black (0,0,0,0)] (color components weighted with alpha)

Your description ("so any time you interpolate from it you end up with grayish intermediate values") sounds like the latter is what you call interpolation in premultiplied RGBA, however you are also stating that what I am currently seeing is interpolation in premultiplied RGBA...

Could you please clear this up? Which of the two examples is interpolated in premultiplied RGBA? And how is the other method called?

[Simon Fraser (smfr)]

*** Bug 156105 has been marked as a duplicate of this bug. ***

[Radar WebKit Bug Importer]

<rdar://problem/25499232>

[Binyamin]

Any progress with this?

[Alexey Proskuryakov]

*** Bug 210365 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

Created attachment 396173 [details]
example

[Philip Jägenstedt]

This issue was mentioned to me while interviewing web developers about browser compat issues. I found this test in web-platform-tests which I think covers the behavior and is failing only in Safari:
https://wpt.fyi/results/css/css-images/gradients-with-transparent.html?run_id=488890002&run_id=483120004&run_id=505970001

Is this still blocked on Core Graphics not supporting it?

[Philip Jägenstedt]

I also found bug 200208, which is about the specific failure I found.

[Darin Adler]

(In reply to Philip Jägenstedt from comment #15)
> Is this still blocked on Core Graphics not supporting it?

Yes.

[Fujii Hironori]

*** This bug has been marked as a duplicate of bug 234492 ***

[Sam Weinig]

Keeping this open for a moment, since we still have not enabled it yet.

We need to decide what perf cost is acceptable for older platforms, and if we should add any additional optimizations like all opaque checking or the extension of that Dan suggested in https://bugs.webkit.org/show_bug.cgi?id=234492#c19.

[Sam Weinig]

Created attachment 447917 [details]
Enable premultiplied interpolation for CSS gradients by default

[EWS]

Committed r287419 (245554@main): <https://commits.webkit.org/245554@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 447917 [details].