Re: [css-compositing] Request to move Compositing and Blending spec to CR

On Tue, Dec 10, 2013 at 11:40 PM, James Robinson <jamesr@google.com> wrote:

> I have an issue with the way the spec defines clip-to-self:
> http://dev.w3.org/fxtf/compositing-1/#groupcompositingcliptoself
> "
> When compositing, the areas of the composite that may be modified by the
> compositing operation, must fall within the shape of the element being
> composited (i.e. where α > 0). This is known as "clip to self" in some
> graphics libraries. The alternative is to not clip the compositing
> operation at all. The results can be seen in the figure below. Some of the
> Porter Duff operators are unchanged, because they normally have no effect
> outside the source region. The changes can be seen in the clear, source,
> source-in, destination-in, source-out and destination-atop.
> "
>
> If I understand correctly, this is defining that compositing only occurs
> when source pixels have alpha > 0.  There are three problems with this
> proposal:
>
> 1.) This introduces a sharp discontinuity between near-zero and zero alpha
> values
> 2.) Due to (1), this is highly susceptible to precision issues in
> implementations
> 3.) This is inconsistent with other web technologies like Canvas
>
> (1) This introduces a sharp discontinuity between near-zero alpha values
> and zero alpha values.  An alpha value of 256 and 255 render very much the
> same, same with a red channel value of 0 vs 1 or any other values.  With
> this clip behavior, an alpha value of zero means "do not apply composite
> operation" whereas one of very nearly but not quite zero means "apply the
> operation" which could result in the final color being entirely different.
>  This can produce unexpected results in cases where the alpha value is
> naturally close to zero, such as with gradiants or low opacity values, but
> especially in combination with (2) - this is highly susceptible to
> precision issues.  Depending on how implementations store alpha values in
> intermediate steps, how they perform blending operations, and the render
> other effects like gradients, filters, text etc two implementations could
> end up with vastly different areas with alpha==0 vs alpha < epsilon on the
> same content.  With this compositing definition, the final output would be
> completely different.  This is a really difficult thing to nail down
> especially as implementations consider using more or fewer bits for alpha -
> for instance doing 10 bit/channel, using per-channel alpha for text AA, or
> using fewer bits for intermediate results.  This has been a continuing
> concrete problem for our implementation in tests that are over-eager about
> checking the alpha values.  Often the results will be perceptually
> identical but have minor differences in low bits of the alpha or color
> channels.
>

James,

I want to say sorry that I didn't read your reply more carefully.

You did indeed point out a flaw in the spec. The "shape" of an element
should never depend on the alpha since, as you point out, it can result in
bad results.
>From the PDF specification:

*Mathematically, elementary objects have "hard" edges, with a shape value
of either 0.0 or 1.0 at every point. However, when such objects are
rasterized to device pixels, the shape values along the boundaries may be *
anti-aliased*, taking on fractional values representing fractional coverage
of those pixels. When such anti-aliasing is performed, it is important to
treat the fractional coverage as shape rather than opacity *


I will pull this from the spec for now and will bring it back (with a
correct definition) in the next revision.


> (3) This is inconsistent with canvas.  If you will remember, several years
> ago different implementations of the CanvasRenderingContext2D interface had
> different behaviors when compositing for non-default compositing modes.
>  Firefox applied the compositing operation to the entire canvas, respecting
> the current clip, and WebKit applied the compositing operation only to the
> "bounds" of the draw.  The issue was there was no reasonable definition of
> the "bounds" of the draw.  The implementation didn't use a alpha=0 test and
> had surprising behavior in some cases.  After much discussion we decided to
> unify on the whole-canvas-respecting-clip behavior.  You can find the
> discussion in the archives.  If CSS compositing behaves differently, it
> both reintroduces the problems we had with canvas and introduces another
> model for web authors to try to deal with an understand.
>
> I think we should change this to the canvas behavior and add a way for
> authors to define the region they wish compositing to apply in, perhaps by
> using CSS shapes.  If that's not considered desirable for this level of the
> spec, we should drop the compositing operations that depend on this and
> reintroduce them in a future level with better clipping behavior.  From the
> limited discussions I can find on the mailing list it seems that these
> cases are considered rather rare for now, so maybe deferring is the way to
> go.
>
> - James
>
>
> On Tue, Dec 3, 2013 at 1:12 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> All,
>>
>> We would like to request that the CSS and SVG WG approve the compositing
>> and blending spec to Candidate Recommendation level. [1]
>> The deadline for comments for Last Call was on November 8 2013 and no
>> changes were requested.
>>
>> The 'isolation' [2] property as mark at-risk since there is only 1
>> partial implementation at this point.
>>
>> The deadline for the earliest progress to PR would be 4 months after CR
>> is published,
>>
>>
>> 1: http://www.w3.org/2005/10/Process-20051014/tr#cfi
>> 2: http://dev.w3.org/fxtf/compositing-1/#isolation
>>
>
>