Re: Utility of background-composite and background-blend-mode?

On Wednesday 2013-03-06 13:06 -0800, Rik Cabanier wrote:
> On Tue, Mar 5, 2013 at 11:05 PM, L. David Baron <dbaron@dbaron.org> wrote:
> > 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 not that simple.  The background image still has to be blended
on top of something.  You're saying that, according to the spec, the
destination that it's blended with is what is drawn below it within
the same stacking context.  And while that might actually be what
you end up with on some testcases, nothing in your patch actually
ensures that the destination buffer contains (a) everything below
the element that is in the same stacking context and (b) nothing
else.  That's not an invariant that Gecko has ever maintained or
needed to maintain.


> > 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.

You still need to specify the destination they're being blended
with.

> > 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.

But it's not what you're doing.

> background-blend-mode works on atomic items that don't need special
> treatment.

Background images themselves are atomic, but you still need to
specify what they're blended with.  And since they don't create a
stacking context, they sit in the middle of the very-complicated
rules for painting stuff within a stacking context.

See http://dbaron.org/log/20130306-compositing-blending for more
explanation of what I mean.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Wednesday, 6 March 2013 23:20:11 UTC