Re: [CSS4 color][CSS4 transition] color pre-multiplied vs non pre-multiplied was (Re: [CSSWG] Minutes TPAC Tue 2012-10-30 AM I: Abstract Directions, Transforms, Transitions)

On Tue, Feb 26, 2013 at 11:00 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> non-premultiplied gradients are not a restriction. I can't think of a single
> design application or graphics library that implements this idiom.
> The CSS WG introduced this so they wouldn't have to special case
> 'transparent'; not because it made sense.

No, we've been over this.  While it's possible to hack gradients by
duplicating the transparent color where the color is distributed on a
line (linear, radial, and the future conical gradients all satisfy
this), this stops working as soon as the color is distributed over an
area, like the mesh gradients being added to SVG.  We don't want to be
inconsistent across our gradient types.

Implementations that can't do premultiplied gradients natively can
hack them by doing the transparent-color duplication behind the
scenes, and then just drawing a non-premultiplied gradient.  They'll
have problems with mesh gradients, but I don't think Core Graphics can
do mesh gradients natively anyway, so it'll require either additions
to CG or some other method to implement.

So, summing up, premultiplied gradients:

* are more convenient for authors, because they don't produce
confusing behavior due to "transparent" having an
otherwise-undetectable color (like a transparent->white gradient being
gray in the middle)
* can't be hacked by authors when doing 2d gradients, like the mesh
gradients being added to SVG2, so we should be consistent across the
gradients
* for the 1d gradients, can be automatically hacked by implementations
that only do non-premultiplied natively, by just duplicating and
coloring "transparent" color-stops behind the scenes

~TJ

Received on Wednesday, 27 February 2013 07:28:32 UTC