- From: Rik Cabanier <cabanier@gmail.com>
- Date: Thu, 10 Nov 2011 13:26:21 -0700
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: Alex Danilo <alex@abbra.com>, www-svg <www-svg@w3.org>, public-fx@w3.org
- Message-ID: <CAGN7qDAZwH2ia=4OyQKHaeQh=dmngQ8h39zHDyo6rs_Abqj2VA@mail.gmail.com>
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
Received on Thursday, 10 November 2011 20:26:53 UTC