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, 6 Mar 2013 20:41:02 -0800
Message-ID: <CAGN7qDAi3z=PTv58=aMJH3ZYoCFAAGt5jEns31e8pMggebZThw@mail.gmail.com>
To: robert@ocallahan.org
Cc: public-fx@w3.org
I have updated the spec:
I added issues on how the backdrop is calculated for CSS and SVG. Should
there a new spec that defines this so compositing and filters can refer to


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]
Received on Thursday, 7 March 2013 04:41:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:44 UTC