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

I create a jsfiddle testcase: http://jsfiddle.net/vSjXM/5/
and attached the rendering of WebKit and Firefox that has the blending
patch. (https://bugzilla.mozilla.org/show_bug.cgi?id=841601)

The behavior you described indeed happens. As soon as an element is
scrolled, it goes to an offscreen bitmap (ffox_scrolling vs
ffox_no_scrolling).
Webkit does not seems to suffer from this. Is this something we can detect
and disable if we detect blending in the element?

Another difference is that 'position: fixed' didn't create a buffer in
Firefox, but it did in WebKit.
It does create a buffer is the scrollable div goes under it; just like you
said :-)

These differences should all be fixed so blending and filter chains that
access the background can work.


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