W3C home > Mailing lists > Public > www-style@w3.org > December 2013

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

From: James Robinson <jamesr@google.com>
Date: Tue, 10 Dec 2013 23:40:38 -0800
Message-ID: <CAD73mdJoo0YV6xSVU6XwrnwUfSjzPEUVFO3UMPz1Kerd=23Z-w@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:17 UTC