- From: James Robinson <jamesr@google.com>
- Date: Tue, 10 Dec 2013 23:40:38 -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: <CAD73mdJoo0YV6xSVU6XwrnwUfSjzPEUVFO3UMPz1Kerd=23Z-w@mail.gmail.com>
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. (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 >
Received on Wednesday, 11 December 2013 07:41:06 UTC