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 15:07:18 -0800
Message-ID: <CAGN7qDAKcKxGShDk-o0vxwtcozFbyLe3eTDu9ykheZ4jzyeU2A@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: robert@ocallahan.org, public-fx@w3.org
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 6 March 2013 23:07:47 GMT