Re: Utility of background-composite and background-blend-mode?

On Wed, Mar 6, 2013 at 6:16 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> On Tue, Mar 5, 2013 at 6:06 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> Hmm. I see that the spec says "Everything in CSS that creates a stacking
>> context <http://www.w3.org/TR/CSS21/zindex.html> must be considered a
>> group." I don't like that. An ancestor that created a stacking context just
>> because it's absolute-positioned with z-index not 'auto' shouldn't impact
>> blending and shouldn't create an isolated group; it'll create a performance
>> penalty for existing Web content.
>>
>
> I agree,but it's just reality.
> The graphics libraries that support the browser's rendering, are not
> powerful enough to create true, non-isolated groups. Even if they did, I
> would have a hard time convincing mobile browsers since it takes a lot more
> processing and extra buffers to implement.
>

I don't understand your answer. I'm arguing that normally stacking contexts
should not be considered groups at all, precisely because we don't want to
have to start using temporary buffers where we currently don't.


>
You also say "In SVG, every element must create a group. This seems costly
>> but implementations can optimize this by not treating elements with default
>> arguments as groups." You also need to check that the element doesn't
>> contain any descendants that use non-default blending. This can be done but
>> it could be costly.
>>
>
> Why is that? a <g> with no properties such as opacity should be treated as
> a passthrough. This is how things are already defined in SVG.
>

Suppose that you have

<svg>
  <circle .../>
  <g>
     <rect style="mix-blend-mode:multiply"/>

According to the spec, the <g> is a group, and to get the semantics right
we'll have to create a temporary buffer for the <g>'s contents even though
the <g> itself has default CSS properties. Right?


>
>> BTW I noticed that you require clip-to-self behavior for compositing.
>> This is tricky because it means you have to define for everything that can
>> be rendered by CSS exactly what the clip-to-self shape is, and it's not
>> always obvious. For this reason we adopted non-clip-to-self behavior for
>> canvas.
>>
>
> True. but clip-to-self is really what authors expect.
> (Note that I called this out in canvas chapter of the spec [1])
> This is one of the reasons that compositing will have to be implemented at
> a later date when the graphics libraries and the hardware are more
> powerful...
> I would be happy to move this to the next level of the spec.
>

Definitely, please. And if you insist on clip-to-self, then when you bring
it back in, it needs to come with definitions for the shapes of everything
CSS can render.


> BTW^32 knockout groups are subtle and under-defined because an "element"
>> doesn't correspond one-to-one with actual drawing operations. For example,
>> if I have an element with a background, border and outline, all of which
>> overlap, does the border knock out the background? Does the outline knock
>> out the border? Note that there could be other content between the border
>> and the outline in z-order.
>>
>
> yes. Like the spec states:
>
> "The end result is as if every shape composites with a ‘clear’ operation
> (with clip-to-self enabled) first before it blends and composites."
>
>
> For instance, if you draw text with multiple shadows and the text color
> and shadows have opacity, knockout would ensure that you won't see the
> shadow through the text or shadow under the other shadows.
>

OK, but it's totally unclear for example whether each text shadow for a
text node is an independent shape or whether all the text-shadows together
constitute a single shape. Or for that matter, whether the text-shadows
constitute a different shape to the text itself. It's unclear whether, when
a node breaks into multiple boxes, the text, background or borders for
different boxes of the node are separate shapes or a single shape. Etc.
This all needs to be specified, for everything CSS can render.


> Getting back to the point of this thread: it seems to me that
>> background-composite and background-blend-mode are not that useful if we
>> have mix-blend-mode and mix-composite. You can do the same sorts of
>> effects, just with more markup. With Web Components and intelligent use of
>> pseudo-elements, you might not even need more markup. I think I'm still in
>> favour of eliminating background-composite and background-blend-mode.
>
>
> I don't disagree. I proposed to move it to a later date a couple of months
> ago but people objected.
> Since the implementation cost is low and the concept easy to grasp, why
> not add it now?
>

Let's see how complicated it is when the spec has been fully worked out.


>  People use background images all the time and I believe that authors
> would like to blend them just like they do in PhotoShop.
> The first example that one of our designers made used mix-blend-mode. He
> just rewrote it to use background-blend-mode and the markup was much
> simpler.
>

Is that example posted somewhere?

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]