- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 6 Mar 2013 15:07:18 -0800
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: robert@ocallahan.org, public-fx@w3.org
- Message-ID: <CAGN7qDAKcKxGShDk-o0vxwtcozFbyLe3eTDu9ykheZ4jzyeU2A@mail.gmail.com>
On Wed, Mar 6, 2013 at 1:06 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > > 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. > oops. I meant to say: It wouldn't make any sense to call a background image a stacking context > > >> 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 23:07:46 UTC