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

On Wed, Mar 6, 2013 at 12:57 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> 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.
>

When does this not happen? (I know 2d transforms sometimes don't)
I think this should be specified. Filters are running into the same issue.


>
>
>>
>  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?
>

It's complicated.
According to the SVG spec, that <g> should be a group with a separate
buffer and set to accumulate (= the background is copied into it) so the
rect and circle blend.
However, FF and WK optimize this case and simply treat the <g> as a
passthrough. The result is that circle and rect still blend. (I'm unsure
what IE does)
I would like to specify that behavior. This will help filters as well since
it allows us to implement background-image [1]

However, this does mean that:

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


The circle and rect won't blend.
If at a later date, browser libraries are more powerful, we can extend
isolation:

<svg>
  <circle .../>
  <g style="opacity: .5; isolation: accumulate">
     <rect style="mix-blend-mode:multiply"/>



>
>
>>
>>> 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.
>

I agree. I will update the spec text.


>
>
>> 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?
>
> Not yet, but I will look into it.

1:
https://dvcs.w3.org/hg/FXTF/raw-file/default/filters/index.html#BackgroundImage