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

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

> On Thu, Mar 7, 2013 at 1:24 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> On Wed, Mar 6, 2013 at 3:25 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>>
>>> 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.
>>
>
> I assure you that positioned elements with z-index are not always
> allocated buffers in Gecko.
>
> You *may* get buffers in some cases. A single fixed-pos child of the
> viewport, with or without a z-index, will probably get its own buffer so we
> can scroll efficiently. Maybe that's why you saw a buffer in your testcase.
>
> As David said in his post, browsers do a lot of complex optimizations
> here. That means we'll need a large test suite for these new blending
> features. It also means we don't want the spec to forbid those
> optimizations or force us to add to their complexity.
>
> Just to give you more of a taste of what Gecko does:
> -- a static abs-pos child of the viewport would not normally get a buffer
>

Yes, that seems to be the case in both FF and WK


> -- but if there's transformed or animated content *under* it, it might
> -- content in a scrollable div will initially be placed into the same
> buffer as the rest of the page
> -- until you start scrolling it, at which point it gets its own buffer,
> and any content overlaying it will get its own buffer too
> -- when you stop scrolling, it will keep its own buffer for a while and
> then dynamically switch back to being part of the page
> The last three points apply even though the entire page is in a single
> stacking context.
>
>
This is very good information. I will extend my testfile so it covers all
these cases.

Rik