- From: Rik Cabanier <cabanier@gmail.com>
- Date: Fri, 13 Dec 2013 20:45:42 -0800
- To: James Robinson <jamesr@google.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: <CAGN7qDC8UgLLOWXTHYukZeHPeAFMgqbswgWdfcPmYTme72qy2w@mail.gmail.com>
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 >> > >
Received on Saturday, 14 December 2013 04:46:26 UTC