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

On Wed, Mar 6, 2013 at 3:25 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Mar 7, 2013 at 11:27 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> 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.
>>
>
> Yes, it should be specified. I gave you an example up above: "An ancestor
> that created a stacking context just because it's absolute-positioned with
> z-index not 'auto' ".
>

that one actually creates a buffer too.
Here is a test file that I created to verify the behavior of stacking
contexts on background blending:

https://github.com/WebKit/webkit/blob/master/LayoutTests/css3/compositing/effect-background-blend-mode-stacking.html


That file doesn't use z-index but I tried that locally. It's the same with
or without z-index and it renders the same on WK and FF.


>
>  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]
>>
>
> Right. That might help, because the spec is currently written would
> require us to do some potentially-hairy optimizations to not regress
> performance of existing content.
>

Yes. Also, I prefer that not all stacking contexts create an offscreen
buffer since they interfere with blending.


>
>
>> 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.
>>
>
> Note that once you've done that, we might have to spend a lot of time
> comparing implementations and fixing them to agree on those shapes :-(. And
> of course someone will have to build a test suite; it's going to have to be
> large.
>

Yes. Luckily, most of that work applies to compositing (which we should
postpone) and not blending. This is because src-over compositing is
unaffected by clip-to-self.