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

On Wed, Dec 11, 2013 at 11:04 AM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
>
> On Wed, Dec 11, 2013 at 10:55 AM, James Robinson <jamesr@google.com>wrote:
>
>>
>>
>>
>> On Wed, Dec 11, 2013 at 9:11 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>>
>>> Hi James,
>>>
>>> thanks for the review!
>>>
>>>
>>> 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
>>>>
>>>
>>> Note that this is for operations that are implemented with
>>> 'clip-to-self'. Currently, there are none.
>>> Compositing for HTML/SVG originally had this feature and this is why it
>>> was cut from the specification.
>>>
>>>
>>
>> OK, if it's not used by any operations let's remove that text from the
>> spec (or clarify what it means).
>>
>
> The definition is still needed so the canvas' non-clip-to-self behavior is
> defined.
>

Canvas is defined in HTML.  Having text here to define a behavior that
canvas does not use is just confusing with no upside.

- James


> As you noted, this was not the case originally and it caused confusion for
> implementors.
>
>
>>
>>>> (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.
>>>>
>>>> (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.
>>>>
>>>
>>> Canvas compositing specifies the following: [1]
>>>
>>> Compositing and blending in canvas 2D must always done with clip-to-self<http://dev.w3.org/fxtf/compositing-1/#groupcompositingcliptoself> assumed
>>> false. This means that a compositing operation may affect the entire canvas
>>> and not just be limited to the shape that is being composited. However, the clipping
>>> region <http://www.w3.org/TR/2dcontext/#clipping-region> will still be
>>> in effect and limit the affected area.
>>>
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> Yes, compositing for CSS was deferred but will be put back in for level
>>> 2. Limiting it to CSS shapes is interesting!
>>>
>>>
>>>>
>>>>
>>>> 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
>>>>>
>>>>
>>> 1: http://dev.w3.org/fxtf/compositing-1/#canvascompositingandblending
>>>
>>>
>>
>