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

On Wed, Dec 11, 2013 at 6:36 PM, James Robinson <jamesr@google.com> wrote:

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

No, canvas refers to the compositing spec for the 'globalComposite'
operator [1]:

The globalCompositeOperation attribute sets the current composition
operator, which controls how shapes and images are drawn onto the scratch
bitmap<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#scratch-bitmap>,
once they have had
globalAlpha<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-globalalpha>
and
the current transformation matrix applied. The possible values are those
defined in the Compositing and Blending specification.
[COMPOSITE]<http://www.whatwg.org/specs/web-apps/current-work/multipage/references.html#refsCOMPOSITE>


Do you think the canvas spec should be more clear that compositing is
defined in the "Compositing and Blending specification"?

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
>>>>
>>>
1:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#compositing