- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 6 Mar 2013 13:06:26 -0800
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: robert@ocallahan.org, public-fx@w3.org
- Message-ID: <CAGN7qDCVMtg5EwFOYEqcngU=G74EQJOAVf04Q99k5tLqr_Hbgg@mail.gmail.com>
On Tue, Mar 5, 2013 at 11:05 PM, L. David Baron <dbaron@dbaron.org> wrote: > On Monday 2013-03-04 22:45 -0800, Rik Cabanier wrote: > > If you follow the spec [1], each background image is drawn during the > step > > '2. background image of element'. The background that is available for > the > > blend operation at that time is everything up to an ancestor that > created a > > stacking context. > > So CSS 2.1 doesn't say any such thing about what background is > available for blending; it only describes the order that things are > painted. > That is correct. The things that are painted make up the background. > > However, what I think you're proposing -- that the background > available for blending is based on what's in the stacking context -- > seems like it's potentially quite expensive, in that it would force > implementations to use a separate graphical buffer for anything that > creates a stacking context, or at the very least anything that > creates a stacking context and has a descendant, in the same > stacking context, with background-blend-mode. That is correct. Are there cases where a stacking context doesn't create a buffer? >From my experiments, only 2d transforms skip this step (and even then they will sometimes create one). From talking to Simon Fraser, this was done intentional to have good quality scaling. > I think it would also > require that implementations *not* use a separate graphical buffer > for anything in that stacking context that might end up underneath > the background, since any such elements would need to be > incorporated into the buffer in order to be composited against. > I don't think there's that requirement. If an implementation used a separate buffer, that buffer would be composited by the time the element with blending accesses the backdrop. > I don't believe your proposed patches to Firefox [2] do this. > That is correct. The patch simply adds support for blending to background images. Only a non-default blend mode to an *element* will establish a new stacking context. > > It's also, as far as I can tell, not specified in the spec [3]. > Correct. Images are buffers anyway :-) It wouldn't make any sense to call a background image a buffer. > I think it would make much more sense to limit the first level of a > compositing and blending specification to the compositing/blending > of elements that establish stacking contexts (and are therefore > atomic). This can include adding new features that cause the > creation of stacking contexts when the features are used. > I *think* that's what I'm trying to do. background-blend-mode works on atomic items that don't need special treatment. mix-blend-mode establishes a new stacking context if you apply it to the element. When mix-blend-mode applies to content, I think it works like specifying it on a background image. When it applies to shadows, borders or background images, there is a need for another buffer. We can postpone that to the next level. > > > 1: http://www.w3.org/TR/CSS21/zindex.html > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=841601 > [3] > https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#background-blend-mode > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla http://www.mozilla.org/ 𝄂 >
Received on Wednesday, 6 March 2013 21:06:57 UTC