W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2013

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Wed, 13 Mar 2013 21:00:19 -0700
Message-ID: <CAGN7qDBjjjmR3A=J4OB0YEwd7y=TRV=u+D17c8k9KhYTz_N=ug@mail.gmail.com>
To: robert@ocallahan.org
Cc: public-fx@w3.org
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
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]

(image/png attachment: ffox_no_scrolling.png)

(image/png attachment: ffox_scrolling.png)

(image/png attachment: safari.png)

Received on Thursday, 14 March 2013 04:00:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:49 UTC