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

On Wed, Mar 6, 2013 at 3:25 PM, Robert O'Callahan <>wrote:

> On Thu, Mar 7, 2013 at 11:27 AM, Rik Cabanier <> wrote:
>> On Wed, Mar 6, 2013 at 12:57 AM, Robert O'Callahan <>wrote:
>>> On Wed, Mar 6, 2013 at 6:16 PM, Rik Cabanier <> wrote:
>>>>  On Tue, Mar 5, 2013 at 6:06 PM, Robert O'Callahan <
>>>>> wrote:
>>>>> Hmm. I see that the spec says "Everything in CSS that creates a stacking
>>>>> context <> 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:

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.

Received on Thursday, 7 March 2013 00:25:23 UTC