- From: James Robinson <jamesr@google.com>
- Date: Wed, 11 Dec 2013 18:36:01 -0800
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: www-style list <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>, www-svg <www-svg@w3.org>
- Message-ID: <CAD73md+uwEWr32OJjKj8PTECjrM74cW9T09KEFzJpgnv2kdXJg@mail.gmail.com>
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 >>> >>> >> >
Received on Thursday, 12 December 2013 02:36:30 UTC