Re: [css-compositing] some proposals

On Tue, Nov 8, 2011 at 10:38 PM, L. David Baron <dbaron@dbaron.org> wrote:

> On Wednesday 2011-11-09 11:43 +1100, Alex Danilo wrote:
> > >- 'enable-background' does not apply. Children with blending will
> composite up to the group with PD blending. (In effect, PD will always
> imply 'enable-background: new')
> >
> > Oh no. PD doesn't ever imply 'enable-background:new' - that's confusing
> it with filters again.
> > P-D is a logical operation on objects not a bitblt operation into a
> backing store (even though
> > many implementations choose to implement it in a similar way).
>
> I don't follow the bit Rik said about "imply"ing enable-background:
> new.


Hi David,

let's say you have the following HTML content:
<div style="enable-background>
 <img id='id_1'/>
 <div comp-op="dst">
  <img id='id_2'/>
  <img id='id_3' style='blending: darken'/>
 </div>
</div>

When calculating the background for the blend on image id_3, would you
include the image with id_1?
If so, how would you calculate this background?

To me, it seems like id_1 should not be used for blending, effectively
making a comp-op of 'dst' equal to 'enable-background: new'


> However, I'm also confused by your reply. Porter-Duff modes
> are all about how to composite two images together.  In most modes,
> that requires knowing both images completely -- you can't have part
> of the "B" image in one buffer and part in another, and then
> composite them together later.  Only with source-over and dest can
> you take (A source-over part-of-B) and then later composite that
> (with source-over) against rest-of-B.  If that's a little vague,
> consider:
>  <div style="background: blue">
>    <div style="opacity: 0.5">
>      <div style="comp-op: source-atop">...</div>
>    </div>
>  </div>
> What is the dest image in the "source atop dest" operation used for
> compositing the innermost div here?  Do we stop at the div with
> opacity, or do we somehow (how?) include what's behind that opacity
> (the blue background of the outermost div) in the dest image being
> composited aganist?


For PD compositing, we stop at the group level.
In this case, that would be the group with the opacity.

If it were a blend mode, you would need to calculate the background image
with the algorithm from
http://www.w3.org/TR/SVG11/filters.html#EnableBackgroundProperty


>
> During the meeting, I asked about how SVG handled this sort of case
> for filters.  After reading through
> http://www.w3.org/TR/SVG11/filters.html#EnableBackgroundProperty , I
> realize that (while SVG's solution to this sort of case for filters
> seems imperfect, though reasonable), SVG is substantially simpler
> than CSS here, since (if my memory is correct) elements in SVG are
> either containers *or* graphical elements, but never both.


I think that correct.


> I don't
> think SVG's EnableBackground algorithm makes sense when elements can
> be both a container and a graphical element, and it's not
> immediately clear to me how to fix it to handle that case.  (And,
> thus, it's not clear to me how to make a 'comp-op' property make
> sense in HTML+CSS.)
>
>
I don't see why this makes a difference.
Couldn't you equal a div with background with a  <g> followed by <rect> the
size of the element?

Rik