- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 6 Mar 2013 20:41:02 -0800
- To: robert@ocallahan.org
- Cc: public-fx@w3.org
- Message-ID: <CAGN7qDAi3z=PTv58=aMJH3ZYoCFAAGt5jEns31e8pMggebZThw@mail.gmail.com>
I have updated the spec: https://dvcs.w3.org/hg/FXTF/rawfile/default/compositing/index.html 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 it? Rik 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