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 13:06:26 -0800
Message-ID: <CAGN7qDCVMtg5EwFOYEqcngU=G74EQJOAVf04Q99k5tLqr_Hbgg@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: robert@ocallahan.org, public-fx@w3.org
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 6 March 2013 21:06:57 GMT